Frequent instances of Status Code 202

[Mark Conner]

For the last couple of weeks, I have been running two RasPis on the 400-406 MHz band for testing purposes.  One of my Pi instances (almost always the same one) will display the following error:

Sondehub Uploader - Error uploading to Sondehub. Status Code: 202 {"message": "some or all payloads could not be processed", "errors": [{"error_message": "DFM radiosonde above 1000 and not enough data to perform z-check. Not adding DB to protect against double frequency usage.", "payload": {"software_name": "radiosonde_auto_rx", "software_version": "1.5.10", "uploader_callsign": "N9XTN-15",.......(rest deleted)

I thought maybe it was because both of them were decoding the same sonde, so I blacklisted the 403.21 frequency on the one that was successfully sending.  However, the other one still gives this error message even after reboots and several minutes have passed.  At the moment, no one else is picking up the 403.21 MHz sonde, so I don't think it's a collision or something at SondeHub.  Any ideas?

73 de Mark N9XTN

[Mark Jessop]

The Z-Check is an attempt to filter dodgy packets from DFM sondes entering the database. It unfortunately does result in some false-positives, hence the error you are seeing. We need this because the DFM sondes telemetry is very prone to packet corruption, especially when there's multiple sondes on the same frequency.

This error can pretty much be ignored, and it should have been inhibited in the latest version... but I confused HTTP codes 201 and 202 :-)

73

Mark VK5QI

--
You received this message because you are subscribed to the Google Groups "radiosonde_auto_rx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiosonde_auto...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/radiosonde_auto_rx/CA%2BTd0WSs6kPweQ2Dr%3DBOrvMZmKeBBQoe5gaLqazp9dFEjg9D_A%40mail.gmail.com.

[Michaela Wheeler]

This is nothing to worry about.

This occurs because of how DFM sondes work - its possible to have two on the same frequency and we have no way to tell the location or ptu data is from which sonde so we use a basic stats check to do this. If you are weak in receiving the sonde you won't receive enough packets for sondehub to perform this check and we'll drop the data - this is fine. We'd rather drop a little bit of data that might be incorrect rather than risk bad data.

https://github.com/projecthorus/sondehub-infra/wiki/DFM-radiosonde-above-1000-and-not-enough-data-to-perform-z-check

-- 

  Michaela Wheeler

  mich...@michaela.lgbt

[Mark Conner]

Thanks for the explanation.  It seemed like it was happening more frequently in the last few days.  Right now I'm tracking a sonde (20058287) that doesn't seem to have successfully uploaded for about 30 minutes even though my local reception seems to be fine (updates every 1-2 seconds).  

73 de Mark N9XTN

To view this discussion on the web visit https://groups.google.com/d/msgid/radiosonde_auto_rx/65dfe45c-24ae-443f-8f8c-f977376cbde8%40www.fastmail.com.

[Michaela Wheeler]

>>> len(a['body']['errors'])

7

I can see from the error messages that you aren't uploading enough data to satisfy the requirement. This might be because of noise, poor snr, distance, another balloon on the same freq. You could try changing the `sondehub_upload_rate` in station.cfg from the default of 15 to 30 (probably don't go higher than this).

Nothing has changed on the sondehub side that would make this any worse recently.

-- 

  Michaela Wheeler

  mich...@michaela.lgbt

[Mark Conner]

Michaela,

Changing sondehub_upload_rate was the key.  I had it set to 10 for some reason.  I have it set to 20 now and is uploading much better.  Thanks for the suggestion!

73 de Mark N9XTN