[pskmail] Re: Robust psk-modes on raspberry pi
- From: Tarmo Huttunen <tarmopaha@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 6 Nov 2013 16:38:19 +0200
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:
