[00:05] <SpacenearUS> New vehicle on the map: 03SQ3AR_chase - 12https://tracker.habhub.org/#!qm=All&q=SQ3AR_chase
[00:14] sumie-dh (~sumie-dh@ left irc: Ping timeout: 245 seconds
[00:20] happysat (~katpoep@s5594c83f.adsl.online.nl) joined #highaltitude.
[00:44] sumie-dh (~sumie-dh@ joined #highaltitude.
[01:13] mcarden (~quassel@ joined #highaltitude.
[01:21] Hoogvlieger (~Hoogvlieg@541A8CEB.cm-5-3c.dynamic.ziggo.nl) joined #highaltitude.
[01:55] Hoogvlieger (~Hoogvlieg@541A8CEB.cm-5-3c.dynamic.ziggo.nl) left irc: Quit: Leaving
[02:08] xau (xxx@unaffiliated/xau) left #highaltitude.
[03:55] tweetBot (~nodebot@philcrump.co.uk) left irc: Remote host closed the connection
[03:55] tweetBot (~nodebot@philcrump.co.uk) joined #highaltitude.
[04:04] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[04:23] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Ping timeout: 255 seconds
[04:29] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[05:08] YO9GJX (~YO9GJX@ left irc: Remote host closed the connection
[05:38] Lahti2 (575d73f2@gateway/web/freenode/ip. joined #highaltitude.
[06:09] chibill (~chibill@108-228-59-57.lightspeed.cicril.sbcglobal.net) joined #highaltitude.
[06:09] <chibill> Hello
[06:29] <TimMc_> hi
[06:30] <TimMc_> I picked up another rs41 radiosonde on the way to work this morning 😂
[06:30] Nilkki (c1416551@gateway/web/freenode/ip. joined #highaltitude.
[06:30] <SA6BSS-Mike> good one!
[06:48] Viproz (~Viproz@unaffiliated/viproz) joined #highaltitude.
[07:07] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 255 seconds
[07:43] rubdos (~rubdos@2a02:578:859d:701:a846:9858:21a:9451) joined #highaltitude.
[07:44] rubdos_ (~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be) left irc: Quit: WeeChat 2.2
[07:54] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[07:58] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Ping timeout: 246 seconds
[08:13] <SpacenearUS> New vehicle on the map: 03SP6ZWR-13 - 12https://tracker.habhub.org/#!qm=All&q=SP6ZWR-13
[08:15] <SpacenearUS> New vehicle on the map: 03SP6ZWR-12 - 12https://tracker.habhub.org/#!qm=All&q=SP6ZWR-12
[08:17] <SA6BSS-Mike> !whereis BSS18
[08:17] <SpacenearUS> 03SA6BSS-Mike: 03BSS18 was over 03North Pacific Ocean 10(32.39583,144.45833) at 0310000 meters about 03an hour ago
[08:22] <SpacenearUS> New vehicle on the map: 03SP6ZWR - 12https://tracker.habhub.org/#!qm=All&q=SP6ZWR
[08:30] cgfbee (~bot@oc1.itim-cj.ro) joined #highaltitude.
[08:30] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:30] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:32] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:32] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:38] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:40] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:41] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:41] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:47] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:48] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:50] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:50] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[08:54] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[08:54] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:02] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:02] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:05] <SpacenearUS> New vehicle on the map: 03SP6ZWR-n - 12https://tracker.habhub.org/#!qm=All&q=SP6ZWR-n
[09:08] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:08] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:14] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:16] mazzanet_ (~mazzanet@unaffiliated/mazzanet) left irc: Quit: Lost terminal
[09:19] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:21] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:26] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:28] mazzanet (~mazzanet@iusedtobeaspy.com) joined #highaltitude.
[09:28] mazzanet (~mazzanet@iusedtobeaspy.com) left irc: Changing host
[09:28] mazzanet (~mazzanet@unaffiliated/mazzanet) joined #highaltitude.
[09:29] Nilkki (c1416551@gateway/web/freenode/ip. left irc: Ping timeout: 256 seconds
[09:37] <SpacenearUS> New position from 03ex2 after 0320 hours silence - 12https://tracker.habhub.org/#!qm=All&q=ex2
[09:37] <SpacenearUS> New position from 03SILTS1 after 0321 hours silence - 12https://tracker.habhub.org/#!qm=All&q=SILTS1
[09:42] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:42] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:46] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[09:46] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[09:47] <SpacenearUS> New vehicle on the map: 03sq6nln_chase - 12https://tracker.habhub.org/#!qm=All&q=sq6nln_chase
[09:58] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[10:00] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[10:02] TimMc_ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Read error: Connection reset by peer
[10:03] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) joined #highaltitude.
[10:41] <mwheeler> TimMc__: nice!
[10:41] <mwheeler> TimMc__: how many do you have now?
[11:06] <TimMc__> @mwheeler 3 x rs41 N, 2 x rs41 P and 4 x radar reflector
[11:07] <TimMc__> stlink is in the post
[11:08] <mwheeler> nice. you'll over take our rs41 collection very soon
[11:09] <Pit[m]> <freenode_Dar "Pit: there's some improvements c"> gps track needs some sanity check, in low SNR scenarios tracks goes crazy https://tracker.sondehub.org/?sondehub=1#!mt=osm&mz=7&qm=All&mc=49.77657,14.48878&f=RS_DFM09-18060017&q=RS_DFM09-18060017
[11:24] <Darkside> Pit[m]: yes, that's a known DFM issue... however that particular bad position would have been stopped if the listening station had set their lat/lon correctly
[11:25] <Darkside> hmm actually in that case maybe nnot
[11:25] <Darkside> there is a radius filter, which will filter out positions further away than that distance from your station
[11:26] <Darkside> but yes, the DFMs are particuarly bad in this - i suspect there may be a checksum we are missing
[11:35] dfm (59cc9a10@gateway/web/freenode/ip. joined #highaltitude.
[11:36] <dfm> the hamming code is kind of checksum
[11:37] chris_99 (uid26561@gateway/web/irccloud.com/x-nyjdikyhiunavmba) joined #highaltitude.
[11:40] <dfm> so if all codewords/bytes are without error, it is very likely that the decoded codeword is the one that was transmitted.
[11:42] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) left irc: Ping timeout: 268 seconds
[11:42] <dfm> If you allow error correction, you need a threshold. If there too many bits in error in a received word, it is likely to be corrected to the "wrong" codeword (not the one that was transmitted).
[11:44] Geoff-G8DHE-m (~Geoff-G8D@geoffg8dhe.plus.com) left irc: Quit: I'm gone please pause the Internet I'll be back shortly ...
[11:44] Geoff-G8DHE_ (~Geoff-G8D@geoffg8dhe.plus.com) left irc: Quit: I'm gone please pause the Internet I'll be back shortly ...
[11:44] Geoff-G8DHE (~Geoff-G8D@geoffg8dhe.plus.com) left irc: Quit: I'm gone please pause the Internet I'll be back shortly ...
[11:47] <dfm> The ohter problem with DFM: The blocks come in pairs, but lat, lon or alt might be in different blocks. If you miss one of them e.g., the position is only updated the other 2 coordinates. You can try to collect the blocks of one frame. This and the threshold is what the --dist option (that should be included in --json) tries to address.
[11:50] <Darkside> ohi dfm
[11:50] <Darkside> so there's no actual frame checksum sent, just the coding?
[11:51] <SpacenearUS> New position from 03ECHO1 after 0312 hours silence - 12https://tracker.habhub.org/#!qm=All&q=ECHO1
[11:51] <SpacenearUS> New position from 03ECHO2 after 0312 hours silence - 12https://tracker.habhub.org/#!qm=All&q=ECHO2
[11:52] <dfm> well, if the hamming code would be in cyclic form, it would be a crc, though short.
[11:52] <Darkside> ok
[11:53] <Darkside> well hopefully with the new sig proc chain we can get a few dB better performance, and reduce the occurence of this a bit
[11:53] <Darkside> havent looked too much into the DFM chain yet, but will get there
[11:54] <Darkside> the RS41 decode chain is now operating pretty close to theoretical non-coherent FSK demod performance, so thats good
[11:54] <dfm> the --dist option reduces false decoding. and you could set a lower threshold.
[11:54] sumie-dh (~sumie-dh@ left irc: Ping timeout: 245 seconds
[11:54] <Darkside> ok, we are not using --dist at the moment
[11:54] <Darkside> i can add that in fairly easily
[11:54] <dfm> I started to play around with you iq-samples and db.
[11:55] <dfm> i think the new version includes --dist in --json.
[11:55] <Darkside> im not 100% confident about the Eb/N0 calibration for anything other than the RS41 samples at the moment
[11:56] <Darkside> i'm checking them by running the signals through david rowe's FSK demodulator, which has a pretty good Eb/N0 estimation routine in it, which has been checked previously
[11:58] <Darkside> yep --dist option is in the version of dfm09dm_dft thats in teh auto_rx repo
[11:58] <Darkside> will also update it to your latest changes
[11:58] <dfm> the rs41 examples behaved similar to the sdrsharp readings. for rs41 you can also measure the noise in between frames and then the signal. in 16bit if you filter, the noise gets very low.
[11:59] <Darkside> yes, i'm only acheiving near theoretical performance with a very tight filter around the signal
[11:59] <Darkside> performance degrades quickly as the filter is widened, as you would expect
[12:00] <dfm> so the downside of --dist is, you don't every frame. sometimes it is good to see as much as possible, also the errors. but when transmitting reliable positions, the threshold should be higher I guess.
[12:01] <Darkside> yes, for auto_rx we only want to send valid positions
[12:01] <Darkside> even if that means losing a few
[12:03] <dfm> I posted my rs41-examples, maybe you have seen. -4800Hz .. 4800Hz bandwitdth filter, still wide, though decodes 9dB. If you output with --ecc2, you see, how the number of cerrected bytes increases when SNR goes down. Up to 2x12=24 bytes can be corrected.
[12:03] TimMc__ (~TimMc_@unaffiliated/timmc/x-5757776) left irc: Quit: -a- 73
[12:04] F5MVO (52e6b25d@gateway/web/freenode/ip. joined #highaltitude.
[12:04] <Darkside> where did you post this?
[12:04] <dfm> If the crc-output gives [00000] (all blocks ok), the frame is correct.
[12:04] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) joined #highaltitude.
[12:06] <dfm> You posted something in connection with the commit: dft_detect: polarity change DFM9=-DFM
[12:07] <Darkside> ok
[12:07] <dfm> It says "Lock conversation", don't even know what this means.
[12:08] <F5MVO> Hello, Darkside, its now ok with radiosonde_auto_rx
[12:08] <Darkside> 9dB Eb/0 seems a bit low - the theoretical performance for a FSK demod at that ebn0 is a BER of 1%
[12:09] <Darkside> which translates to a pretty high packet error rate - though i guess error correction will clean that up a lot
[12:09] <dfm> 9dB with reed-solomon.
[12:09] <Darkside> yeah i wondering what the coding gain there is
[12:09] <Darkside> what the code rate?
[12:09] <dfm> Yes, that's why I would use the --ecc2 output, to see, what ecc is doing.
[12:10] <dfm> RS(255,231)
[12:11] <dfm> 24 parity, 231 msg bytes.
[12:12] <Darkside> ok, so still a pretty high rate code
[12:12] <dfm> Only the full aux-frames have 2x255 bytes, so the standard frames have 320(-8 hdr) bytes, 2 codewords.
[12:13] <dfm> The code is good, needs more computation.
[12:13] <Darkside> ahh ok! it is 320 bytes per frame
[12:13] <Darkside> hmmm
[12:13] <dfm> Hamming is easy to implement.
[12:14] <dfm> the stand frame 320 would have ca rate 2x24/(320-8)
[12:15] <Darkside> ok
[12:15] <dfm> but the shortened code is better for decoding.
[12:15] <Darkside> im just thinking about how to translate the BER curves for FSK to a PER curve that we can use to compare against acheived performance
[12:15] <dfm> the vaisala frames are good.
[12:15] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) left irc: Ping timeout: 246 seconds
[12:15] <dfm> m10 has no ecc, althoug there is so much space left.
[12:16] <Darkside> yeah i think vaisala decode performance is pretty damn good at the moment
[12:16] FireFighter (~firefight@2601:44:4200:ab4f:6056:5ebb:2c1e:30e7) joined #highaltitude.
[12:16] <Darkside> i just need to fix the decode chain a bit
[12:16] <Darkside> dfm: would being passed soft-decisions help your decoder in any way?
[12:17] <Darkside> because fsk_demod can output floating point soft-bits
[12:17] <dfm> I included errasures, so if you find the right positions, yes.
[12:18] <dfm> but it 2:1, either you need several passes or a good decission, what soft-decoded byte is a candidate for errasure.
[12:18] <Darkside> so far i've been experimenting with using fsk_demod as a fsk demodulator and 'cleanup' in some sense
[12:18] <dfm> I played around with it. Sometimes it helps.
[12:18] <Darkside> cat filename | csdr shift_addition_cc 0.25 2>/dev/null | csdr convert_f_s16 | ../bin/fsk_demod --cs16 -b 1 -u 45000 2 96000 4800 - - 2>/dev/null | python ../bin/bit_to_samples.py 48000 4800 | sox -t raw -r 48k -e unsigned-integer -b 8 -c 1 - -r 48000 -b 8 -t wav - 2>/dev/null| ./rs41ecc --options
[12:19] <Darkside> that gives the same performance as a tight filter FM demod, but with the benefit of not having to be precisely on frequency
[12:20] <Darkside> if its within the passband of the receiver, it'll find it and still give the same performance
[12:20] <dfm> In post-processing, when you have a demaged frame, there can be done a lot. automated it is not so easy.
[12:21] <Darkside> python ../bin/bit_to_samples.py 48000 4800 is my hack to make fsk_Demod output work with your decoder - fsk_demod outputs one-byte-per-bit (0x00, 0x01), which i convert to an 'ideal' FM demodulator output (i.e. 0x00 or 0xff)
[12:21] <Darkside> and for however many samples is necessary for the symbol length
[12:21] <dfm> Even with iq-demodulation, you filter somewhere.
[12:22] <Darkside> yes, in this case its matched filters over the tones
[12:22] <dfm> if i have time, i would like to do everything on my own.
[12:22] <Darkside> hence ending up with similar performance
[12:22] <dfm> 1) to learn of course
[12:23] <dfm> 2) as you said, you can apply the frequency-offset estimate to the iq-stream without leaving your program.
[12:24] <dfm> low pass (band) filtering is not a problem. With 48k decimated sample rate, the processing optimization is not so important i guess.
[12:25] <Darkside> all of this stuff is very low rate, so no real issues with CPU on anything faster than a Pi 2 or so
[12:26] <dfm> Still want to decode iq-samples, but there are more parameters; FM makes many things easier, the deviation for example is not important.
[12:28] <Darkside> i just like the idea of not having to have the receiver precisely on frequency - helps if the sonde (or receiver) drifts a bit
[12:28] <dfm> And I don't bother the gaussian FM pulse shape, the integrate phase-pulse is similar.
[12:29] <Darkside> yes, appanretly the performance gain from just a straight FSK demodulator to doing a proper GFSK demod isnt really that much
[12:29] <dfm> offsets of 800hz or so I shift in iq.
[12:30] <dfm> The FM-average/dc is easy to correct.
[12:30] <Darkside> hmm sounds like a different appproach to what david is doing
[12:30] <Darkside> afaik he does tone estimation, which allows for any tone spacing (within some restrictions
[12:30] <Darkside> then runs matched filters over the detected tone locations
[12:31] <dfm> for m10 i do this, so there is this carrier on the upper side, from which it deciates down. if you use a highpass e.g., you see how it adjust in the preamble.
[12:31] <Darkside> https://www.rowetel.com/?p=4629
[12:32] <dfm> with iq-samples, the rs41-preamble gives you a very good frequency estimate.
[12:33] <dfm> then the manchester-coded signals have these tones you can look for.
[12:33] <dfm> the scrambled code of rs41 is not so clear, although the modulation index gives sharp edges.
[12:34] <Darkside> yeah i was qute surprised at how 'clean' a RS41 signal looks
[12:37] <dfm> when comparing to gnuradio-output and when measuring the phase-deviation, I had the impression, the modulation index is somewhere 0.8, gaussian shape make the deviation smaller, when bits change frequently, but for 1.0 the frequency spectrum should be different, more like rs92.
[12:37] <dfm> Don't know, if dave takes the gaussian part into account.
[12:39] <dfm> gfsk is a little bit worse to decode than fsk, that's the trade-off for narrow bandwidth, i guess.
[12:39] <Darkside> yeah fsk_demod doesnt do that afaik
[12:39] <Darkside> which means theres a slight performance hit
[12:39] <Darkside> but not enough to matter i think
[12:39] <Darkside> i think the tradeoff of being able to have it lock onto a drifting/off-frequency signal is worth it
[12:40] F5MVO (52e6b25d@gateway/web/freenode/ip. left irc: Quit: Page closed
[12:40] <Darkside> the 1680 MHz sondes in teh US are a big problem in that regard
[12:40] <Darkside> their drift is much worse compared to the 400 mhz stuff
[12:40] <dfm> So I think you can improve there a bit, but I don't know how sensitive it is to different receiver-output.
[12:41] <SpacenearUS> New vehicle on the map: 03SH04 - 12https://tracker.habhub.org/#!qm=All&q=SH04
[12:41] <Darkside> yeah the trick with auto_rx is we kind of enforce a particular receiver chain (RTLSDR -> our code)
[12:41] <Darkside> so we can do these kinds of tweaks
[12:42] <dfm> So maybe airspy
[12:42] <Darkside> yeah i want to support more SDR types in teh future
[12:42] <dfm> But this helps. The audio-decoding is most universal, everyone can use it.
[12:42] <Darkside> oh definitely
[12:43] <Darkside> im just saying for auto_rx i'll try and use whatever works best
[12:43] <Darkside> since its more of an automated system
[12:45] <Darkside> though an option in your demods to accept one-byte-per-bit input would make my life easier :P
[12:45] <dfm> So the frequeny offset / position can be found with FFT, I have a small program to replace rtl_power, so I can look for peaks in the c-code.
[12:45] <Darkside> yeah i saw that
[12:45] <Darkside> tbh rtl_power isnt that hard to replace - as you've shown
[12:45] <Darkside> its more just a time thing
[12:45] <dfm> You could use the --rawin/--rawhex input
[12:45] <Darkside> hmm theres a point, i havent tried that yet
[12:46] <Darkside> that is --rawin expecting?
[12:46] <dfm> pack your bits to a byte.
[12:46] <Darkside> doesnt matter about alignment, or framing starts?
[12:46] <dfm> I have --rawin to read -r output as text-lines.
[12:46] <Darkside> ok, will give it a go
[12:47] <dfm> so in rs41iq i included to read the xored-raw-text
[12:47] <dfm> have to look, if it is in git.
[12:47] <Darkside> hrm, does rs41dm_dft have rawin?
[12:47] happysat (~katpoep@s5594c83f.adsl.online.nl) left irc: Remote host closed the connection
[12:48] <Darkside> i see it has a --raw option, not sure if thats the same thing
[12:48] <dfm> have to look, but rs41ptu has it.
[12:48] <dfm> if you don#t modulate, it doesn't make a difference.
[12:49] <dfm> but it expect the descrambled sequence. you would have to apply descrambling first.
[12:49] <dfm> wait
[12:49] <Darkside> conerting to 'ideal' FM demod output isnt particularly hard to do
[12:49] <Darkside> and if you're using hard decisions on that, it would essentially be the same result anyway
[12:49] <Darkside> just maybe a little bit less CPU
[12:49] <dfm> the rs41dm_iq.c has the --xorhex option
[12:50] <dfm> --rawhex takes as input, what -r outputs.
[12:50] <dfm> --xorhex takes text-file input, that is not descrambled.
[12:51] <dfm> if you pack your bits into bytes and then to hex-string, you can read it with --xorhex.
[12:51] happysat (~katpoep@s5594c83f.adsl.online.nl) joined #highaltitude.
[12:51] <dfm> though you have to start with the header.
[12:52] <Darkside> yeah cant really do that easily...
[12:52] <dfm> the frame would start like this
[12:52] <dfm> 8635f44093df1a60...
[12:52] <Darkside> mm
[12:52] <Darkside> probably easier to just keep on doing it how i'v ebeen doing it so far
[12:52] <dfm> with python?
[12:52] sumie-dh (~sumie-dh@cst2-62-95.cust.vodafone.cz) joined #highaltitude.
[12:53] <Darkside> well i'll convert that bit to C :P
[12:53] <Darkside> that was just a quick hack to convert to the samples
[12:54] <Darkside> 0x01 -> 0xFFFFFFFFFFFFFFFFFF
[12:54] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) joined #highaltitude.
[12:54] <dfm> bit/byte input could be included. however if you want header-recognition, it would complicated it.
[12:54] <Darkside> i guess the point is to just bypass the bit slicer part
[12:55] <Darkside> anyway, not urgent
[12:55] <dfm> well, you have to know the byte boundaries.
[12:55] <Darkside> different question - have you looked into humidity support on the RS41s?
[12:55] <Darkside> i think theres someone in this channel with some info on the calibration calculations for that
[12:56] <dfm> so maybe header-recognition should be done in rs41-decoder.
[12:56] <dfm> will see, a test-version shouldn't be so complicated.
[12:56] <dfm> no, not yet.
[12:57] <dfm> a while a go, temperature was on the list.
[12:58] <dfm> the calibration seems to work the right way.
[12:58] <dfm> first i wanted to do humidity for m10 and dfm.
[12:58] <dfm> the chips are known.
[12:58] <dfm> the raw data too.
[12:59] <Darkside> http://rfhead.net/sondes/samples/rs41_byte_per_bit.bin
[12:59] <dfm> but in low temperature, it depends on temperature.
[12:59] <Darkside> yeah i've seen the calculations for it
[12:59] <dfm> one could ask the manufacturer for temperature dependency at -50C.
[13:00] <Darkside> makes you wonder how much cal data is not actually sent down with teh sonde, and is determined on the ground
[13:00] <dfm> i hvae a lot of recordings that i could compare to the publicated data.
[13:00] <dfm> some day, i will probably look at the data again.
[13:01] <dfm> it is not as accurate as temperature, so i didn't include it.
[13:01] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) left irc: Ping timeout: 268 seconds
[13:02] <dfm> so humidity is a problem at high altitudes, anyway, it is not very accurate, response time is high and so on. (from what i read)
[13:02] <Darkside> ok, makes sense
[13:03] <dfm> rs41 is a bit different.
[13:03] <dfm> the pt1000 without calibration was useless, but it provides this data.
[13:04] <dfm> so with humidity it is similar, a bit more complex. and i think they post process humidity anyway.
[13:04] <Darkside> oh, so that above byte-per-bit sample, i convert it for use with rs41dm_dft using: cat sample | python ../bin/bit_to_samples.py 48000 4800 | sox -t raw -r 48k -e unsigned-integer -b 8 -c 1 - -r 48000 -b 8 -t wav - 2>/dev/null| ./rs41dm_dft
[13:04] <Darkside> the bit_to_samples.py script is here: http://rfhead.net/sondes/samples/bit_to_samples.py
[13:04] <Darkside> dodgy hack that it is
[13:05] <Darkside> that hack is not going to work for baud rates that dont multiply up nicely to 48000Hz, like the DFM and M10
[13:05] <Darkside> frigging 9614 Hz baud rate?!!?!?
[13:06] <Darkside> and 2500 Hz???? weird!
[13:06] <dfm> but the demodulator does not know the byte boundaries, same with python!?
[13:07] <dfm> i guess it should be 9600. but then after sync at the beginning, it will not go through the whole frame.
[13:08] <Darkside> the demod just outputs one bit at a time
[13:08] <dfm> for m10, manchester, in between synchronization would help, manchester helps here.
[13:08] <Darkside> it doesnt know anything about byte boundaries or framing
[13:09] <dfm> that's why it has to be done in the decoder, so you cannot pack it into bytes before that.
[13:09] <Darkside> just the raw decision from the matched filters, either as a soft-decision output (float) or a hard decision (0x00 or 0x01)
[13:09] <Darkside> yeah exactly
[13:10] <dfm> no, i will put a test-rs41 together for this. it is not so different from what is done now.
[13:11] <dfm> by for manchester this would waste the effort made, when spreading 1 bit to 2 symbols.
[13:12] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) joined #highaltitude.
[13:12] <Darkside> yeah im not saying this is an ideal solution in all cases - what we have now (with the right fm demod settings) works well enough
[13:13] <Darkside> right, i need to get to bed, getting late here!
[13:13] <Darkside> good to chat!
[13:13] trickv_ (uid348170@gateway/web/irccloud.com/x-bdguwccfdjlatquf) joined #highaltitude.
[13:15] dfm (59cc9a10@gateway/web/freenode/ip. left irc:
[13:22] dfm (59cc9a10@gateway/web/freenode/ip. joined #highaltitude.
[13:23] <dfm> iq-decoding right now is done in a rather naive wav, cf. https://github.com/rs1729/RS/blob/master/iq/iq_demod.pdf (german).
[13:24] <dfm> it is a first step, to say where it is important to improve.
[13:25] <dfm> i believe fsk_demod does something similar, probably better synchronization/tracking, some filtering, and this is probably important when working with phase instead of frequency.
[13:26] dfm (59cc9a10@gateway/web/freenode/ip. left irc: Client Quit
[13:32] shiftplusone (~shift@unaffiliated/shiftplusone) left irc: Ping timeout: 258 seconds
[13:33] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) left irc: Ping timeout: 268 seconds
[13:40] shiftplusone (~shift@unaffiliated/shiftplusone) joined #highaltitude.
[13:40] chibill (chibill@108-228-59-57.lightspeed.cicril.sbcglobal.net) left #highaltitude ("Be back later...").
[13:46] richardeoin (~richard@ec2-35-176-87-167.eu-west-2.compute.amazonaws.com) joined #highaltitude.
[13:48] dfm (59cc9a10@gateway/web/freenode/ip. joined #highaltitude.
[13:48] <dfm> @darkside
[13:51] <dfm> another hack would be, spread the bit to (samples_per_bit-many)samples, bit1: 0.5, bit:-0.5, rectangular shape no problem, with a sox-wav-header it would emulate the fm-signal-stream.
[13:52] <dfm> bit0:-0.5
[13:52] <dfm> bit1:+0.5
[13:52] dfm (59cc9a10@gateway/web/freenode/ip. left irc: Client Quit
[13:52] Geoff-G8DHE_ (~Geoff-G8D@geoffg8dhe.plus.com) joined #highaltitude.
[13:52] Geoff-G8DHE-m (~Geoff-G8D@geoffg8dhe.plus.com) joined #highaltitude.
[13:53] Geoff-G8DHE (~Geoff-G8D@geoffg8dhe.plus.com) joined #highaltitude.
[14:18] solletichino999 (02edada4@gateway/web/freenode/ip. joined #highaltitude.
[14:27] solletichino999 (02edada4@gateway/web/freenode/ip. left irc: Quit: Page closed
[14:36] <SpacenearUS> New vehicle on the map: 03oe6pod_chase - 12https://tracker.habhub.org/#!qm=All&q=oe6pod_chase
[15:24] The20YearIRCloud (uid38883@gateway/web/irccloud.com/x-gmrtehgsggfnhoje) left irc: Quit: Connection closed for inactivity
[15:30] YO9GJX (~YO9GJX@ joined #highaltitude.
[16:31] paul__ (5191a782@gateway/web/freenode/ip. joined #highaltitude.
[16:31] paul__ (5191a782@gateway/web/freenode/ip. left irc: Client Quit
[16:33] dfm (59cc99db@gateway/web/freenode/ip. joined #highaltitude.
[16:34] <dfm> @darkside: the reason why i'm a bit reserved about dave's fsk_demod, i didn't like that the blog posts sound to much like self-marketing and that all the other demodulators were crap. i think that's a bit unfair if you don't know the whole story.
[16:34] <dfm> maybe there are compatibility or historical reasons or different purpose of the demodulators, some are just meant to be simple and most general, not supposed to be the best demodulators of the world. and takes the comparison all parameters into account?
[16:34] <dfm> then again, in the gmsk-code he admits he does not understand why the xor-logic?! that is not so complicated, but maybe i misunderstood the remark. And then i read he compares DMR with it's own FSK, but they use different modulation indeces, have different bandwidth?
[16:35] <dfm> i don't know, probably i make the same mistake right now, since i certainly don't know the whole story.
[16:36] dfm (59cc99db@gateway/web/freenode/ip. left irc: Client Quit
[16:54] <SpacenearUS> New vehicle on the map: 03KF4ZTI-11 - 12https://tracker.habhub.org/#!qm=All&q=KF4ZTI-11
[17:28] <SpacenearUS> New position from 03BSS18 after 0311 hours silence - 12https://tracker.habhub.org/#!qm=All&q=BSS18
[17:34] sumie-dh (~sumie-dh@cst2-62-95.cust.vodafone.cz) left irc: Ping timeout: 245 seconds
[17:43] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) joined #highaltitude.
[18:21] sumie-dh (~sumie-dh@ joined #highaltitude.
[18:29] Viproz (~Viproz@unaffiliated/viproz) joined #highaltitude.
[18:32] PE2BZ (~pe2bz@162-066-045-062.dynamic.caiway.nl) left irc: Ping timeout: 246 seconds
[18:37] <chris_99> thought this talk was really interesting - https://www.youtube.com/watch?v=T3dGLqZrjIQ 'LoRa crash course by Thomas Telkamp'
[18:47] SA6BSS-Mike (~SA6BSS-Mi@ left irc: Read error: Connection reset by peer
[18:49] SA6BSS-Mike (~SA6BSS-Mi@h-155-4-222-217.NA.cust.bahnhof.se) joined #highaltitude.
[18:55] <chris_99> i'm not sure if i fully realised that higher bandwidth results in more loss over a distance (iirc he said that's due to the antenna)
[19:02] <SA6BSS-Mike> Voyager Is data bit rate was 21.6 kbps at the beginning, now it is decreased to 160 bit per second - Distance :)
[19:03] <chris_99> wow, interesting, they decreased that programmatically?
[19:04] <chris_99> or..
[19:05] <SA6BSS-Mike> if you have the energy, https://descanso.jpl.nasa.gov/DPSummary/Descanso4--Voyager_new.pdf
[19:05] <chris_99> cheers!
[19:06] <chris_99> it amazes me how far away voyager is
[19:06] <chris_99> and how it still communicates
[19:07] <SA6BSS-Mike> its mindblowing realy!
[19:07] <SA6BSS-Mike> its like seeing 20W lamp in far away space
[19:09] <chris_99> https://voyager.jpl.nasa.gov/mission/status/ has some crazy figures
[19:11] <chris_99> just reading this https://en.wikipedia.org/wiki/Voyager_1 'the craft's RTGs will continue to support some of its operations until 2025' that's a shame if it runs out of power then
[19:13] chandroid (~chandroid@bqu140.neoplus.adsl.tpnet.pl) left irc: Ping timeout: 250 seconds
[19:14] chandroid (~chandroid@btj228.neoplus.adsl.tpnet.pl) joined #highaltitude.
[19:29] <Ian_> Don't tell me that it's using Ultimate Energiser Lithium batteries :)
[19:29] <chris_99> haha
[19:43] ASDFoster (~ASDFoster@unaffiliated/asdfoster) joined #highaltitude.
[19:47] trickv_ (uid348170@gateway/web/irccloud.com/x-bdguwccfdjlatquf) left irc: Quit: Connection closed for inactivity
[19:49] DocBrown (59cc99db@gateway/web/freenode/ip. joined #highaltitude.
[19:49] <DocBrown> It requires something with a little more kick ...
[19:49] DocBrown (59cc99db@gateway/web/freenode/ip. left irc: Client Quit
[20:02] PE2BZ (~pe2bz@162-066-045-062.dynamic.caiway.nl) joined #highaltitude.
[20:07] FireFighter (~firefight@2601:44:4200:ab4f:6056:5ebb:2c1e:30e7) left irc: Remote host closed the connection
[20:37] dfm (59cc9994@gateway/web/freenode/ip. joined #highaltitude.
[20:42] <dfm> @darkside rs41 coderate: aux-frames 231/255, standard frame 132/156.
[20:46] <dfm> What I was trying to say: Hamming [8,4] code is easy to implement. With todays microcontrollers Reed-Solomon is not a problem anymore. for framelength/baudrates radiosondes use, probably just right. For M10 it could improve receiving alot.
[20:48] <dfm> Or at least shorter crc-blocks, not only one checksum at the end.
[20:54] <Viproz> dfm, how do you want to do that for M10 ?
[20:59] <Viproz> oh talking about IQ decoding ? Cause other than trying to take a guess at which bit is wrong and testing the CRC of the whole frame each time I don't see anything more to improve the detection
[21:01] <Viproz> well could try to get the most likely value out of previous non CRC frame and replace the bytes of the new frame with them but I don't think we would get a real dB improvement with that
[21:01] Lahti2 (575d73f2@gateway/web/freenode/ip. left irc: Quit: Page closed
[21:11] chris_99 (uid26561@gateway/web/irccloud.com/x-nyjdikyhiunavmba) left irc:
[21:15] Laurenceb (laurence@cca100-pool11.nottingham.ac.uk) left #highaltitude.
[21:17] Kodar (~Kodar@93-142-44-229.adsl.net.t-com.hr) joined #highaltitude.
[21:17] Ian_ (4d66af83@gateway/web/freenode/ip. left irc: Ping timeout: 256 seconds
[21:23] <dfm> No, the M10 is like it is. But if you would do it again, or a new version.
[21:25] <dfm> M10 has no error correction code. But it would be nice to have it, and the frames are so short, enough bytes left to inculde some parity bytes.
[21:26] <Viproz> oh yeah, I guess they just don't care since the part they want to decode is when it's pretty high up so no need for fancy decoding algorithms
[21:26] <Viproz> the manchester encoding enough is probably good
[21:27] <dfm> Trying to flip possible bit-errors amounts in many possibilities very quick.
[21:28] <Viproz> yeah but the CRC is only 2 bytes, would be quick to get a false positive (assuming the CRC is pseudo random)
[21:30] <dfm> If you implement error correction code like Reed-Solomon, you do it only once.
[21:32] <dfm> I think the Sippican Mk2a repeats every frame (also has crc). So they wanted to have redundancy, though in a very simple way.
[21:34] <Viproz> Darkside, I would be curious, did you try running the M10 decoder on your samples with and without the -b option ? In my code it adds a new decoding where instead of summing the sample values directly it sums the normalized value (so -1 is negative or +1 if sample positive), if this is something effective we could implement it for the rest of the decoders
[21:35] <dfm> You integrate/sum the samples, right?
[21:35] <Viproz> yep
[21:36] Heppie_M0XBC (51686179@gateway/web/freenode/ip. joined #highaltitude.
[21:36] <dfm> I do it with -b as well. And with manchester (-b2) over both symbols, longer integration. I think you do something similar.
[21:36] <Viproz> the sync is a bit weird, I try to calculate the exact match but I've seen on a few samples that is I just use 0.3 (meaning that the first sample is 70% owned by the first rawbit of the payload) I get better results
[21:37] <dfm> So most important is to have the right timing, i.e. to find the bit boundaries.
[21:37] <Heppie_M0XBC> Hi all. Has anyone had issues with radiosonde auto rx recently misidentifying sondes?
[21:37] <Viproz> Heppie_M0XBC, you're detecting a M10 instad of a RS41 ?
[21:37] <Heppie_M0XBC> indeed
[21:38] <dfm> Integrating all samples is a bit like matching rectangular pulses, and the m10 pulses are almost rectangular.
[21:38] <Viproz> yep, Darkside is working on it :)
[21:38] <Heppie_M0XBC> cool :)
[21:38] Kodar (~Kodar@93-142-44-229.adsl.net.t-com.hr) left irc: Ping timeout: 245 seconds
[21:38] <Heppie_M0XBC> Thanks Viproz
[21:39] test120948 (57b7f460@gateway/web/freenode/ip. joined #highaltitude.
[21:39] <Pit[m]> test
[21:40] Action: Pit[m] uploaded an image: image.png (858KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/vtzRJTFXxvWgSqRgYUIRpUmp >
[21:40] <dfm> So you can weight or discard the first/last samples, but with only a few samples per bit, maybe it is best to up-sample to 96k (or 96.16k?)
[21:40] <Pit[m]> cool i can paste images from the clipboard and it generates a link for irc user,. nice
[21:40] <Pit[m]> matrix is cool, but a little bit slow
[21:40] <Viproz> dfm, I've been hitting my head on a wall trying to detect the header by integrating while still having a good sync but I really don't know how to, I can't trust any data the only thing I've thought of is to find the best match by summing the values and optimizing to one sample but I wanted to do decimals
[21:41] <Viproz> yeah would be good if I can implement an integrating header match, right now it adds too much noise and maes it worse
[21:41] test120948 (57b7f460@gateway/web/freenode/ip. left irc: Client Quit
[21:42] <dfm> You could also integrate over bitlength all the time, and then just dump at the right time, maybe +/-1 sample. If you do this, maybe the header-synchronisation works better, since it is kind of lowpass. Or you use a lowpass in the first place.
[21:43] <Darkside> Heppie_M0XBC: to clarify - dfm here has solved it - i just need to integrate it into auto_rx :-)
[21:43] <Heppie_M0XBC> Awesome work :)
[21:44] <Viproz> yeah I should stop worrying about decimal header pos, I have the code to integrate continuously, just need to find the best match and pass on the data to my main function
[21:45] Kodar (~Kodar@93-139-161-27.adsl.net.t-com.hr) joined #highaltitude.
[21:46] <dfm> Take a circular buffer where you put the last x samples in, x the bitlength. For each sample, also sum up the buffer and compare. If you plot both, the averaged sample is filtered, and you would do it anyway, so later you just need to pick the avg at the right moments.
[21:46] <Viproz> dfm, I guessed you were Zilog while talking but didn't confirm, nice to see you here :)
[21:47] <dfm> darkside, when i read you py-script, you have done this already, from one bit to sample_rate/baudrate samples... but i inlcuded bit-input in rs41ptu.c
[21:49] <Viproz> https://gist.github.com/Viproz/8e98f4d28def20d448ee8209ade05ce9#file-sdfdfs-cpp-L98 this is what I was planning on using, to sum all of the sums to get a kind of "correlation" value or something
[21:49] <dfm> Well, the correlation of several headers is a bit cpu-consuming. You could switch of radiosondes that you don't want to decode anyway. But maybe it can be optimized a little bit.
[21:50] <Darkside> dfm: dft_detect seems to run fast enough on a pi 2 to beusable
[21:50] <dfm> When they do voice-call-matching, I could imagine they compare many wav-forms, many they know how to do it...
[21:50] <Darkside> i'm going to have a go at integrating it, and seeing how it goes - but i think its OK as it is
[21:51] <dfm> Don't know, if these guys would share their methods though.
[21:52] <Viproz> aren't we using deep neural net for voice match ?
[21:53] <dfm> You want to match your header (correlation) for every new sample coming in until you find your header?
[21:54] <dfm> In principle, yes, and you need a window to look where your best match is.
[21:54] <Viproz> The plan was to do it until and after, when the sum goes down I know I passed the peak correlation, I didn't do performance test though :D
[21:55] <dfm> but in this way you do a lot of processing. Thats why I have the correlation/without DFT) still their, you can compare how long it takes.
[21:56] <dfm> Correlation is like convolution, and to save time, you take the fourier transform, multiply, and go back.
[21:58] Maxell_ (~Maxell@duplex.bewaar.me) left irc: Ping timeout: 246 seconds
[21:58] <dfm> don't know how they find interesting calls, there are certainly a lot of candidates. Probably their is some deep learning involved nowadays.
[21:58] Maxell (~Maxell@duplex.bewaar.me) joined #highaltitude.
[22:00] <dfm> Maybe deep learning could help demodulating, guessing what the transmitted bit was, before noise.
[22:01] <Viproz> to reconize the shape of the wavform maybe, I debugged quite a bit by hand and I was able to see the noise and the bad parts and to correct them, never was able to code this so maybe a neural net could be appropriate
[22:02] <Viproz> I'm not getting into that though
[22:02] <dfm> In modern communications with high bitrates, they use other codes anyway.
[22:04] <dfm> Yes, thats what I meant. When you look at it and know what to do, that deep learning can learn this to. I mean they do this e.g. to recognize traffic signs and other patterns.
[22:04] <dfm> pattern recognition.
[22:05] <dfm> Correlation is very good, when you know what you are looking for, headers e.g.
[22:05] <dfm> But the data bits are changing, thats a bit different.
[22:06] <Viproz> for the M10 they are always very similar, it probably makes it simpler
[22:08] Kodar (~Kodar@93-139-161-27.adsl.net.t-com.hr) left irc: Ping timeout: 246 seconds
[22:08] <dfm> 1 manchester bit is very short. if you spread you bit over more symbols, you can match better. but you spread your energy over a wider bandwidth, so you could also use smaller bandwidth/baudrate.
[22:10] BrainDamage (~BrainDama@unaffiliated/braindamage) left irc: Ping timeout: 244 seconds
[22:10] vaizki (znc@arkki.vaizki.fi) left irc: Quit: ZNC - http://znc.in
[22:10] vaizki (znc@arkki.vaizki.fi) joined #highaltitude.
[22:10] <dfm> and that's not why manchester code is used. the average/dc is 0, thats the primary goal.
[22:11] ETE (~quassel@a80-101-233-106.adsl.xs4all.nl) left irc: Ping timeout: 244 seconds
[22:11] Ian_ (4d66af83@gateway/web/freenode/ip. joined #highaltitude.
[22:12] BrainDamage (~BrainDama@unaffiliated/braindamage) joined #highaltitude.
[22:13] ETE (~quassel@a80-101-233-106.adsl.xs4all.nl) joined #highaltitude.
[22:21] <Viproz> now I really want to code but I need to go to work tomorrow, I'll try to finish my code for Wednesday :p
[22:24] dfm (59cc9994@gateway/web/freenode/ip. left irc:
[22:24] Kodar (~Kodar@93-139-180-191.adsl.net.t-com.hr) joined #highaltitude.
[22:31] <SpacenearUS> New vehicle on the map: 03SQ5NWI - 12https://tracker.habhub.org/#!qm=All&q=SQ5NWI
[22:33] <Heppie_M0XBC> Why is ZNC such a pain to configure
[22:33] Kodar (~Kodar@93-139-180-191.adsl.net.t-com.hr) left irc: Ping timeout: 245 seconds
[22:36] happysat (~katpoep@s5594c83f.adsl.online.nl) left irc: Remote host closed the connection
[22:39] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 255 seconds
[22:40] happysat (~katpoep@s5594c83f.adsl.online.nl) joined #highaltitude.
[22:41] Heppie_M0XBC (51686179@gateway/web/freenode/ip. left irc: Quit: Page closed
[23:32] The20YearIRCloud (uid38883@gateway/web/irccloud.com/x-rpttefmnlycyossg) joined #highaltitude.
[23:38] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) left irc: Remote host closed the connection
[23:48] happysat (~katpoep@s5594c83f.adsl.online.nl) left irc: Quit: Hunger-the-inner-diva
[23:52] happysat (~katpoep@s5594c83f.adsl.online.nl) joined #highaltitude.
[00:00] --- Tue Feb 26 2019