[pskmail] Re: Robust psk-modes on raspberry pi
- From: Tarmo Huttunen <tarmopaha@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Tue, 19 Nov 2013 12:42:40 +0200
Excellent, thanks :)
Tarmo
19.11.2013 2.10 "John Douyere" <vk2eta@xxxxxxxxx> kirjoitti:
> Tarmo,
>
> The following patch fixes the bug. It exists also in X86 architectures but
> it resolves differently and works regardless!
>
> In psk.cxx, in the subroutine rx_symbol(...), replace the line:
>
> softbit = (unsigned char) ((softangle / (1 + softamp)) -
> 127);
> by:
>
> softbit = (unsigned char) ((softangle / (1 + softamp)) +
> 127);
>
> It has worked for others.
>
> Regards,
>
> John
>
>
> On Fri, Nov 8, 2013 at 8:35 AM, John Douyere <vk2eta@xxxxxxxxx> wrote:
>
>> Hello Tarmo,
>>
>> I have rechecked on both 386 and Android platforms and the THOR modes are
>> more CPU intensive than PSKR modes on both platforms.
>>
>> Do you get proper decode in PSKR modes?
>>
>> Can you check the CPU load and memory usage with a "top" command for
>> example?
>>
>> 73, John
>>
>>
>> On Thu, Nov 7, 2013 at 1:38 AM, Tarmo Huttunen <tarmopaha@xxxxxxxxx>wrote:
>>
>>> I had short time to play with raspi today. I compared captured rx/tx
>>> text on logfile to text on fldigi GUI.
>>>
>>> When fldigi receive rsid for psk-r mode, (125, 250 or 500) it stops
>>> writing to logfile. Also received pskr-rsid will not be written to logfile,
>>> even it will show up normally on GUI received text window.
>>>
>>> In thor 22, when rsid is received, notification will be written to
>>> logfile.
>>>
>>> Raspi can send psk-r modes normally, it was only bad cable.
>>>
>>> I will be googling this subject later, to check if this problem have
>>> appeared on other platforms.
>>>
>>> Tarmo
>>> On Nov 5, 2013 11:27 AM, "Tarmo Huttunen" <tarmopaha@xxxxxxxxx> wrote:
>>>
>>>> John, you really now what you are talking about!
>>>>
>>>> Reason I started to think this is the fact that raspi indeed handels
>>>> thor22 well, even with medium sink interpolator, but not psk-r modes at
>>>> all. Or lets say I have never get it decoding psk-r, not even slower ones.
>>>>
>>>> You kind of confirmed my thoughts. I take this subject from back of my
>>>> mind to my table, start to look it closer when I have time. After all I
>>>> havent use raspi much after recent audio-related updates.
>>>>
>>>> Thanks, Tarmo
>>>> On Nov 5, 2013 4:04 AM, "John Douyere" <vk2eta@xxxxxxxxx> wrote:
>>>>
>>>>> Hello Tarmo,
>>>>>
>>>>> If you have correct decoding with PSK modes but not PSKR modes then
>>>>> the most likely reason is processing power.
>>>>>
>>>>> The processing load on the CPU is significantly higher due to the
>>>>> double Viterbi decoder and interleavers used for the PSKR decode.
>>>>>
>>>>> I have seen that issue on the earlier Android devices when I developed
>>>>> the andPskmail program.
>>>>>
>>>>> If you look at the rxpsk source code in the Android program (in Java)
>>>>> you will see that I spend time to work around these limitations. One
>>>>> solution I used quite effectively was to reduce the order of the filters
>>>>> to
>>>>> free-up some resources.
>>>>>
>>>>> From memory I reduce the order from 64 to 32, which means a slight out
>>>>> of band increase in interference but overall better than not having decode
>>>>> at all.
>>>>>
>>>>> But if you say that TXing is also not decodable, then I suspect that
>>>>> the CPU is simply not capable of processing that load.
>>>>>
>>>>> A good test would be to try the MFSK and THOR modes as well because
>>>>> the MFSK modes are very resource effective and the THOR modes the most CPU
>>>>> hungry.
>>>>>
>>>>> In my experience on the Android devices (from memory) here is the
>>>>> approximate hierarchy of CPU load by mode:
>>>>>
>>>>> PSK31
>>>>> ...
>>>>> PSK500
>>>>> MFSK16
>>>>> ...
>>>>> MFSK64
>>>>> PSK63F
>>>>> PSK125R
>>>>> ...
>>>>> PSK500R
>>>>> THOR8
>>>>> ...
>>>>> THOR22
>>>>>
>>>>> So have a look if the top of the list works but not the bottom. That
>>>>> should give you a good indication if the CPU is the issue or not.
>>>>>
>>>>> Also, have a look in Fldigi what interpolator you use. The linear one
>>>>> is the most CPU efficient.
>>>>>
>>>>> I also assume you have already selected the "Slow CPU" option in
>>>>> Fldigi.
>>>>>
>>>>> 73, John
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 5, 2013 at 12:03 PM, Tarmo Huttunen
>>>>> <tarmopaha@xxxxxxxxx>wrote:
>>>>>
>>>>>> Hello...
>>>>>>
>>>>>> I have wondered this oddity with raspberry-fldigi-jpskmail for a
>>>>>> while:
>>>>>>
>>>>>> Psk-r modes are not working. Sympton is, after psk-r id is received,
>>>>>> raspberry does not decode anything. I mean, there will not come any
>>>>>> characters on fldigi window. Is that "normal" sympton related to slow
>>>>>> cpu?
>>>>>>
>>>>>> In normal pc-setups if psk-r decoding fails, there will come at least
>>>>>> some nonsense text, am I right?
>>>>>>
>>>>>> I have started to wonder, if this psk-r problem is after all related
>>>>>> to prosessing power at all? Could this have something to do with varicode
>>>>>> used on psk-r modes? Missing symboltable or something similar?
>>>>>>
>>>>>> If I remember right, I also havent got pc to decode psk-r sent by
>>>>>> raspberry. (This was not what I was testing, just something I happend to
>>>>>> notice, and I am at work now, can not test again.)
>>>>>>
>>>>>> Do somebody have some advice for me, where should I look? Have
>>>>>> somebody used robust psk-modes on some other low-resource machine?
>>>>>>
>>>>>> Thanks
>>>>>> Tarmo, OH6ECF
>>>>>>
>>>>>
>>>>>
>>
>
Other related posts:
