SparkSDR 2.0.2.7

[Alan Hopper]

Hi Group,

there is a new release here http://www.ihopper.org/radio/previews.htm it has a few perfomance tweaks, better use of screen space for spots and frequency snapping when double clicking.

I have not put the mac version on that page as It may still have a nasty bug that causes a crash but if anyone wants to test it it is here http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_2_7_osx.app.tar.gz

73 Alan M0NNB

[Dan Porter]

Hi Alan,
So far so good on my iMac. Thanks!
73, Dan - AI2M

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/1bee283a-42fd-469d-8078-467b5be5a016o%40googlegroups.com.

[Steve Haynal]

Hi Alan,

I've updated to the latest SparkSDR and my pskreporter spot count is now pretty much what I'd expect it to be. I'm leading for my region of North America west coast! Look for "Hermes-Lite" in the top reporter rankings. The reserved CPUs helped, but I was still seeing EP6 errors. I am still using cpu sets to reserve one cpu for the most active SparkSDR thread, and that pretty much eliminates EP6 errors. I see the message "dropped" many times in the terminal where I am running SparkSDR. What does that mean? When using my Python scripts to examine the .adif logs, I still see a few bogus calls:

Bad Call cm88

Bad Call rr73

Bad Call signal73

Bad Call jh44

Bad Call rr73

Bad Call ft4

Bad Call rr73

Bad Call cm95

Bad Call rr73

Bad Call rr73

The count on pskreporter agrees with my Python scripts now to within 1% difference. This is much better than the ~30% difference I was seeing before. Thanks for all your work!

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

That's good to know, thanks for all your analysis on this. I'll tweak my callsign filter a bit although I'd prefer it to let a few through rather than filter out some valid ones.  The dropped message should not be there but it indicates things got a bit busy and an ft8 15s period was dropped from being decoded, this is done if the decode queue gets longer than 2 minutes. The Decode Rate give the percentage not dropped.  I still have to sort out linux thread priorities.

73 Alan M0NNB

[neil whiting]

I have had mine running for most of a day now.

The Linux machine with 10RX HL2 is the most stressed. I still had to use Steve's shielding technique to avoid excessive EP6 errors.

Decode rate is 98.86 and I have only 1 "dropped" message. The machine is definitely underpowered for the job and I could do

with a better one but high performance nowadays seems to come at a high cost. 

It might be more cost-effective to buy (yet) another HL2 and run in 6RX mode where the PC has no trouble keeping up.

73,  Neil  G4BRK

[Sven Palmersjö]

Hi Allan!

Still see ep6 which could be massive and few depending of how many reserve cores and how deep decoding is, I think, I use.  Could SNR with poor conditions have something to do with this?

Just now I have 12 cores reserved, decoding 2 and poor conditions. It doesn't work so well in PSK Reporter but hard to see which setup could be better!

73 de Sven SM6FMB

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/a7611ea4-074d-438b-94f3-9966919b1265o%40googlegroups.com.

[svem...@gmail.com]

Hi!

I should add that I use Windows 10, latest SpakSDR 2.0.2.7 and want to use high/low on 2 Herme Lite 2.

73 de Sven SM6FMB

[Steve Haynal]

Hi Alan,

This 2.0.2.7 release has been working great the last few days. I downloaded my .adif log each day and compared the pskreport spot number to what my Python scripts say and they were always within 1%. I am only running on 9 bands since this is a remote underpowered machine at my sister's place and noise on 160M is awful there. To try to reduce the dropped messages, I switched to decode depth of 2. I didn't restart SparkSDR. Do you have to restart for that change to apply?

73,

Steve

kf7o

 

[Alan Hopper]

Hi Steve,

as long as you set the decode depth per receiver it should apply on the next decode. The default depth in settings only applies when you create a receiver from scratch (not from a profile).

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

I switched to decode depth of 2 for all receivers and no longer see the dropped messages. I expected my spot count to go down but it has remained about the same. Maybe I was dropping enough to be equivalent to a decode depth of 2? I like that you can set the decode depth per receiver and will try switching back to 3 for a few receivers. Do you or others know or have experience with what the deeper decode depth is best for? For example, I am wondering if the lower frequency bands with more noise will benefit more from the deeper decoding.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

an interesting question that I don't have an answer to. I've not studied the decoder very much but my feeling is the deepest mode takes more cpu when there are lots of spots so maybe there are gains to use it on the quieter bands, on the other hand it possibly uncovers more spots on the busy bands as I think it is good at finding signals partially covered by bigger ones.  I shall add some stats to show cpu per band/mode along with uploads per band.

73 Alan M0NNB

[Joe LB1HI]

Hi,  So far so good but RX antenna switching button is missing

73, Joe

[Alan Hopper]

Hi Joe,

good to hear it is working for you. I hid the antenna button whilst we work out what should be done in software, gateware and hardware for switching on ptt, It would be good to restart the discussion on the Hermes Lite group. I'm on holiday at the moment but will release a new version very soon (mainly with fm stuff) and could re enable it then but it won't have the switching on ptt initially.  I think we need a big diagram of all the switching options.

73 Alan M0NNB

[Alan Hopper]

Hi Mac users,

just wondered if anyone has had any problems with 2.0.2.7 on mac, if it has magicaly fixed the crash I'll mark it as a stable version.

73 Alan M0NNB

[Dan Porter]

Hi Alan,

I haven’t used it very much because I have been experimenting with Simon’s SDR Console on Windows 10 in Boot Camp on my iMac. I discovered the other day that the Wideband DSP Noise Blanker removes enough of the interference from my upstairs neighbor’s Plasma TV for me to still make successful FT8 QSOs.

That said, I do remember some flickering video of just the Spark SDR window, but thought it may be a problem unique to my iMac, because it works ok on my MacBook Pro.

Thanks,
Dan

--

You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/7a5fbc2a-cdc7-4d30-b045-5ede1eca661fo%40googlegroups.com.

[ahop...@googlemail.com]

Hi Dan,

thanks for the report, Peter has also reported the flicker and I have seen it a couple of times on my very old macbook, as no one had mentioned it I thought/hoped it was just my old machine. 

73 Alan M0NNB

[KL3RR]

Hello all,

Did anyone else running a 24/7 multi band SparkSDR 2.0.2.7 spotter get an email recently from PG7V regarding bad calls, specifically on JT65?

See below:

>From PG7V <pg7v@....>

>to kl3rr

>Dear OM,

>It seems your SDR receiver is generating wrong spots in mode JT65. When I check the JT65 page on www.hamspots.net/jt65 I see a lot of unexisting callsigns:

>I also checked your spots in other modes, spots in mode FT8 are all OK, so it seems there is a problem with JT65.
>Is it possible for you to check what's going wrong, or maybe disable JT65, so these wrong spots will disappear?

>Thanks in advance!

>73, Jan PG7V

It looks like he is correct and there are invalid calls being reported and accepted by pskreporter.info.  I am not sure why JT65 would be more affected than other modes.  I know that the recent versions of SparkSDR have had some work to try to minimize reporting of invalid call signs. 

KL3RR

[Alan Hopper]

Hi,KL3RR

just so I understand, are all those spots invalid? If not which ones are. If they are not callsigns does anyone recognize them as something else? The text will have come from the wsjtx decoder so either they are wrongly decoded or I am mistaking something else for a callsign, they don't appear to be locators.

73 Alan M0NNB

[KL3RR]

I only checked a few of the call signs (when I received the list) and in all cases my station was the only one to report the supposed spot on pskreporter.   I don't know that every single callsign on the list is in error, but based on the first few that I did check, I assumed that PG7V was correct in stating the majority were reported in error. 

According to PG7V, at least some of the reports from the other callsign on this list, KK4WJS (another  SparkSDR station), were also invalid.  It seems probable that all SparkSDR stations would experience this same issue.

I was hoping that the invalid callsigns and the issue causing them could be easily identified by knowledgeable persons.  Apparently it is not that clear. 

I've provided PG7V with the link to this thread in case he is able to chime in with more information.

Regards,

Eugen KL3RR

[Alan Hopper]

Hi Eugen and PG7V,

I'll do what ever I can to ensure only correct spots are uploaded but I would like to understand how these are considered to be invalid. If it is simply that you are the only reporter, I wonder if that is just that you  are simply the only person that heard them, with the rise of ft8 and ft4 there are far fewer people listening to jt65 and spark is fairly unique in that it allows skimming many modes at once so maybe they are genuine spots. I'm very open to ideas as to what is happening here but looking through my code I can only think that the wsjtx decoder believes them to be real so all ideas are very welcome.

73 Alan M0NNB

[KL3RR]

Hello,

I emailed PG7V requesting more clarification on which spots were invalid and how to identify them. 

Received this reply:

>PG7V

>to KL3RR

>Hi Eugen,

>I'm sorry to say, but almost all spots I mailed you are invalid. Most of the callsign/prefixes just don't make sence, so it's immediately clear that they are invalid. Only W9YAI seems to be a >valid callsign and is listed on QRZ.COM.

>As I already wrote to you, I also tried to mail KK4WJS, but couldn't find an e-mailaddress. So I also mailed to VK3AMA, he is running the website hamspots.net. I asked him if possible to >block JT65 from KK4WJS and you, because there were more invalid spots on this page than real valid spots. He replied to me that he has blocked both KK4WJS and you for JT65 spots. >Sorry for KK4WJS and you, but all these invalid spots.

>I don't know where things are going wrong, but both KK4WJS and your SparkSDR are generating really strange spots, you can see immediately that they are invalid, some examples:
>3/N6/5
>7RI5/ER9IEU
>E7VG/DS4CSN
>SGG2/V34FIP
>M8K47
>And several other callsign that seem to be ok, but are with prefixes that are not in use for that particular country.

>That's all info I can give, I really hope it's possible to find the error, so that nobody has to be blocked from any spotting system.

>73,
>Jan PG7V

Eugen KL3RR

[neil whiting]

I do sometimes see bad calls coming out of WSJT-X but quite rarely.

It may be less of a problem on FT8 as there are so many good decodes they are not noticed.

I don't normally run JT65 as activity is quite low nowadays, but I have added some for several bands to my

skimming to see if I can get any more evidence. I've had a couple of bad ones so far, but don't seem to be able to

copy/paste from the Spark window to here. They don't look anything like callsigns and have not appeared on PSKReporter.

73,  Neil  G4BRK

[neil whiting]

I found them in the appdata\. . . .\decoded.txt , they had not been overwritten yet:

0805   2  -30 -3.51   3040.  -1   LH1C5E.U3TAWK          JT65  9  1  0
0805   2  -30  0.25    501.  16   ?QACPZIPNPORA          JT65  9  1  0

I'll see if I get any that look more like callsigns over the next few hours.

73,  Neil  G4BRK

[ahop...@googlemail.com]

Hi Neil,

thanks for that, it is a bit tricky to sort out when there are so few signals

I have received IKJIXNB7PQ8? and QRZ 340PTN MN71 the first would not be reported but do you know what the second one means?

73 Alan M0NNB

[neil whiting]

OK, got two now which looks real but aren't - they don't appear on PSKReporter but do on Hamspots:

0820   2  -30  0.17   1514.  13   318 WM4IHD II27        JT65  1  1  0

0830   2  -16 -1.74    373.  -2   A1DQP KV2GFT BJ55      JT65  9  1  0

Common to most of the 7 I have seen is a low reported signal strength of -30 or -29,

but KV2GFT is an anomaly.

It seems PSKReporter does a good job of filtering these out but Hamspots does not.

[neil whiting]

Hi Alan,

Not sure if I have seen one like the second, but it looks like a typical WSJT-X mis-decode.

I've seen these sort of errors before running WSJT-X with my K3, so I don't think it's a SparkSDR

issue. I've added a DigiU RX piped to WSJT-X and I'll see what that recovers.

I can see several similar bad callsigns being reported on Hamspots from WY7W on 7MHz but don't know what

setup he is using.

73, Neil

[ahop...@googlemail.com]

Hi Neil,

I'm starting to wonder if this is just what happens when you leave a decoder running on very quiet bands, the number of false decodes will simply be a much bigger percentage than on a busy band as all the decodes are either noise or very distant or weak signals. Someone using jt65 to communucate will not stay on a silent band so is less likely to report these spots, so maybe spark is one of the few things listening. I did wonder if JT65 was being used for nefarious means.

73 Alan M0NNB

[neil whiting]

Hi Alan,

I'm sure that is part of it, but there may be something else going on.

I left things running for a couple of hours on 30m with a SparkSDR |RX doing the normal JT9/JT65 decoding and another virtual RX feeding samples to WSJT-X.

Results from SparkSDR:

During that time I got just 2 decodes from WSJT-X v2.2.1, both good:

1251 -12 0.2 2708 # CQ DL6CHF JO52

1253 -16 0.2 2708 # CQ DL6CHF JO52

All the other decodes from Spark are errors (the ones which look like good callsigns have very wrong locators).

I don't know if the latest WSJT-X does filtering of decodes before reporting them on the screen.

Improved suppression of false decodes was in the release notes for a recent version.

Not quite sure what more debug I can  do  - I am probably going to be blacklisted on Hamspots soon!

It might be interesting to be able to retain wav files which result in decode and the dfecoded text as a debug option -

the wav files could then be loaded into WSJT-X for comparison. You may well have done this comparison already.

73, Neil  G4BRK

[ahop...@googlemail.com]

Hi Neil,

that's interesting, what decode depth were you using?

73 Alan M0NNB

[neil whiting]

Hi Alan,

Deep decode depth.

I've been playing with settings on WSJT-X as I wasn't decoding quite a few that Spark was.

It's working better now so I'll leave it running.

I do get some false decodes with WSJT-X but it seems not as many as with Spark. I'll try to quantify that better

with today's run.

73,  Neil  G4BRK

[neil whiting]

Hi Alan,

Over 0730z to 1010z this morning on 10MHz I got 9 bad decodes on SparkSDR and

9 on WSJT-X. So it seems not too much difference after all once WSJT-X was decoding properly.

A few of the more believable ones from both were reported on PSKReporter but somewhat more

were shown on Hamspots.

So it seems it is the filtering on PSKReporter which is working better than Hamspots in taking out

some of the bad decodes from WSJT-X.

So it looks like what you said earlier is the truth - that leaving a decoder running on a quiet band gives a

much bigger percentage of bad decodes. And this is exacerbated on Hamspots by the spot filtering being less

aggressive.

73,  Neil  G4BRK

[ahop...@googlemail.com]

Hi Neil,

thanks for that, I am also seeing as many bad spots in wsjtx. I've never looked at Hamspots before and have not really worked out what it does yet, where does it get its spot data from?

73 Alan M0NNB

[Joe LB1HI]

Hi Alan,

The function of the RX antenna control is obvious and the same for decades.

We do not want to have a strong signal from our own antenna while transmitting at the receiver's input.

73`s

Joe, lb1hi

[ahop...@googlemail.com]

Hi Joe,

the 2.0.2.9 release enables the GP7 control, if you want this to only enable on rx the best way is to combine the signal with ptt the same way the hp filter on the N2ADR does it.

73 Alan M0NNB

[Joe LB1HI]

Thanks Alan for the responses and the restoration of the RX Antenna Control button.
In October, I will certainly test it and share my experiences.

Good luck with further software development.

And thank you for your efforts so far.

With a slight humor if we can have any three wishes.

So far I will say one wish. Namely, a good working Wide Noise blanker. NBW

73, Joe

[J P Watters]

Alan,

I am running the MACOS version SparkSDR 2.0.2.9, and it is running with out any of the previous crashes or glitches. !!!!!

is there support for ATU operations?  ie https://github.com/softerhardware/Hermes-Lite2/tree/master/hardware/enclosure/endcaps/kf7o/hl2_40b#atu

For example a button to press to activate the AutoTuner.

..jpw J P Watters

KC9KKO

Morris, IL USA

[ahop...@googlemail.com]

Hi Joe,

sorry for my slow response, I really don't like the new google groups layout, I find it too easy to miss new stuff.  I have been giving a noise blanker some thought, Dr Warren Pratt's take on this in thetis and powersdr is the most sophisticated I know of, I'm interested to know of any other approaches.

73 Alan M0NNB

[ahop...@googlemail.com]

Hi jpw,

good to know it is working for you, I'm aware there are some issues for some mac users an am concentrating most of my effort on getting a solid release out for all platforms at the moment.  In recent releases the atu bit should be set when the tune button is used but I've not tested and have had no feedback that it actually works.

73 Alan M0NNB