highaltitude.log.20190302

[00:03] <Viproz> Darkside, I think it's exiting correctly now ?
[00:04] <Darkside> try with some samples i guess/
[00:04] <Darkside> lol nice commit comment
[00:05] <Viproz> I can't get used to the fact that true doesn't exist x)
[00:06] <Darkside> hahaha
[00:07] <Darkside> yup that does it
[00:07] <Darkside> thanks LD
[00:08] <Darkside> :)
[00:08] <Viproz> I'm trying to see for the sdr part, I'll butcher everything in another branch and we'll see
[00:08] <Darkside> haha
[00:08] <Darkside> comment out all the things
[00:09] <SpacenearUS> New vehicle on the map: 03VK2GJ-11 - 12https://tracker.habhub.org/#!qm=All&q=VK2GJ-11
[00:10] Viproz_ (~Viproz@unaffiliated/viproz) joined #highaltitude.
[00:14] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 245 seconds
[00:16] tjq (uid339161@gateway/web/irccloud.com/x-znuzwhwxfoajlpyy) joined #highaltitude.
[00:25] <Viproz_> yeah getting rid of the SDR is a lot harder, I don't understand threads and things like this that are used in the file
[00:25] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[00:25] <Viproz_> the way it works now is that it just replaces the data when it reads it from the SDR to data from a file
[00:26] Nick change: Viproz_ -> Viproz
[00:27] <TimMc_> hello from irssi
[00:28] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Client Quit
[00:29] <SpacenearUS> New vehicle on the map: 03CDJ3 - 12https://tracker.habhub.org/#!qm=All&q=CDJ3
[00:30] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[00:31] happysat (~katpoep@s5594c83f.adsl.online.nl) left irc: Remote host closed the connection
[00:32] <SpacenearUS> New position from 03U3B-25 after 038 hours silence - 12https://tracker.habhub.org/#!qm=All&q=U3B-25
[00:42] <Viproz> I was able to recieve the M10 in flight finally, I just need an LNA to compensate the long shitty cable I need to go under a door and something to put the antenna above the roof rather then below !
[00:45] <TimMc_> now using irssi on a VPS. hopefully less reconnects
[00:58] <Darkside> Viproz: heh
[00:58] <Darkside> Viproz: ut the VNE at the other end!
[01:01] <Viproz> Darkside, VNE ? Very Noisy Electronics ?
[01:01] <Darkside> VNA
[01:01] <Darkside> :P
[01:01] <Darkside> shush you
[01:02] <Viproz> I don't know what VNA is either x)
[01:02] <Darkside> urgh
[01:02] <Darkside> LNA
[01:02] <Darkside> ffs
[01:02] <Darkside> caffeine hasnt kicked in yet
[01:02] <Darkside> its only 11:30AM
[01:04] <Viproz> ah okay ! I stilk don't get what a LNA would do at the other end though ^^
[01:05] <Darkside> so the overall aim of a receive system is to lower the receive system noise figure
[01:05] <Darkside> noise figure being a measure of degradation of SNR from 'ideal' (thermal noise limited) performance
[01:06] <Viproz> one solution could be to put the SDR outside and run a slim usb cqble inside but I'm not sure the SDR is weatherproof
[01:06] <Darkside> the noise figure of a system (think - antenna, amplifiers, coax, receivers, connected together in different ways) cascades
[01:06] <Darkside> howver the system noise figure is dominated by the NF of the first device in the chain
[01:07] <Darkside> so if you put a low noise figure amplifier (LNA) right at the antenna, the *system* noise figure will be pretty close to that of the LNA
[01:07] <Darkside> resulting in better performance
[01:07] <Viproz> yeah that's why I want to put an LNA right at the antenna
[01:07] <Darkside> yup
[01:07] <Viproz> I just don't have any yet
[01:07] <Darkside> heh
[01:08] <Darkside> https://store.uputronics.com/index.php?route=product/product&path=59&product_id=54
[01:08] <Darkside> these are excellent for radiosondes
[01:09] <Viproz> yeah but that's 50 bucks, it's painful, more expensive than an sdr
[01:09] <Darkside> running coax is better than running USB
[01:09] <Darkside> and the performance will be better than just a SDR at the feedpoint
[01:10] <Darkside> the noise figure of those RTLSDRs is not great, and their intermod performance is worse
[01:10] sumie-dh (~sumie-dh@78.108.102.220) joined #highaltitude.
[01:10] <Darkside> so putting a preamp and a filter in front of them increases performance dramatically
[01:15] <Viproz> I'll see tomorrow I need to get some sleep but it would sure be nice, Ican see FM all over the place right now
[01:31] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 250 seconds
[02:04] BitEvil (~quassel@tor/regular/SpeedEvil) joined #highaltitude.
[02:04] Nick change: SpeedEvil -> Guest19394
[02:05] Guest19394 (~quassel@tor/regular/SpeedEvil) left irc: Ping timeout: 245 seconds
[02:19] dfm (59cc992e@gateway/web/freenode/ip.89.204.153.46) joined #highaltitude.
[02:22] <dfm> dft_detect: you can lower the threshold (correlation can detect known signals in noise very good), though decoding will not be very successful.
[02:22] <Darkside> yeah
[02:22] <Darkside> dfm: im currently writing some code to run dft_detect over all the samples, and show the resultant correlation scores
[02:23] <Darkside> that way i can determine the optimal thresholds
[02:23] <dfm> Then it decodes the header and counts the bit-errors. If you allow more errors (right now it is only 1 bit), then you also detect more frames.
[02:23] <Darkside> the aim here is that the detector should detect at the lowest SNR that the decoder chains will successful decode
[02:24] <Darkside> at the moment that isn't the case, as we're running the detecter with a wider FM bandwidth, so it can pick up all sonde types with a single pass
[02:24] <Darkside> the performnce of the individual demod chains is better, as we can use narrower filters
[02:24] <dfm> I have put out the running correlation in a second wav-channel, then you see the peaks every second.
[02:24] <Darkside> i've written some code to print out the max observed correlation score at the end of the processing
[02:26] <dfm> If you have more noise due to bandwidth, lower the threshold and maybe switch off header-check. For rs41 the check is not needed, it has a very unique header.
[02:27] <Darkside> ok will have a play with that
[02:27] <Darkside> i also need to balance this with the peak detection threshold
[02:27] <dfm> Or at least allow up to 4 bit errors-
[02:28] happysat (~katpoep@s5594c83f.adsl.online.nl) joined #highaltitude.
[02:28] <dfm> For dfm it could be lower, but then you can decoding errors.
[02:29] <dfm> But you can try to estimate the bandwidth from the fft-scan, before you run the detect-tool
[02:29] <Darkside> yes thats a point
[02:29] <Darkside> i was wondering about some kind of correlation of the FFT scan results with some known masks
[02:30] <dfm> bandwidth is either 6-10kHz or 16-20kHz approx, or 32 or 60 for the afsk
[02:30] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[02:30] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[02:30] <dfm> Yes, with enough resolution on the fft you see the radiosonde type.
[02:32] <dfm> for the m10 it should be considered anyway, because of the one-sided carrier.
[02:32] <Darkside> yeah M10 is the problem child here
[02:32] <Darkside> wider, has that weird idle carrier
[02:33] <dfm> it is the upper frequency, from there the signal deviates down.
[02:33] <Darkside> yes thats what i mean
[02:33] <Darkside> its like they are keying a FSK carrier from a UART or somethign
[02:34] <dfm> Don't know why it transmits idle, at least it is more quiet in FM.
[02:37] <dfm> I was thinking of integrating the fft in short slices, the m10 transmits very short frames.
[02:37] <Darkside> at the moment M10 detection is very good
[02:37] <Darkside> very very good
[02:37] <Darkside> i think part of that comes from it being such a short header
[02:38] <dfm> the carrier shifts the "center of gravity", when integrating.
[02:38] <dfm> but if you know it's m10, it is okay.
[02:39] <Darkside> i noticed you're paying with the LMS6s too?
[02:39] <Darkside> anythign special about them?
[02:39] <dfm> Though the signal is weaker the a signal that transmits the whole second.
[02:40] <Darkside> if i can get some LMS6 samples, it could be easily added to auto_Rx, and then the guys in the US might be able to play
[02:40] <dfm> Well, there is a kind of LMS6 flying in Canada. It looked similar, but I don't know the LMS radiosondes.
[02:40] <Darkside> ok
[02:41] <dfm> don't know if it is old or a new test prototype.
[02:41] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[02:41] <dfm> but in principle it shouldn't be a problem to integrate lms6.
[02:42] <Darkside> a lot of the sondes being on the 1680 mhz band in the US makes things more difficult too
[02:42] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[02:42] <Darkside> drift is more pronounced
[02:42] <dfm> but in the us, they sold these frequencies, as far as i know.
[02:42] <dfm> so they switch more and more to 400mhz
[02:42] <Darkside> so they should be moving to 400 mhz?
[02:42] <Darkside> ok excellent
[02:42] <Darkside> i know they are still flying RS92-AGPs in california
[02:43] <dfm> this new one is detected as lms6. don't know if i will include it, it is like m10/m10+.
[02:44] <dfm> right now i just don't know what it is.
[02:44] <dfm> AGP? with GMSK?
[02:44] <Darkside> its basically a RS92 but on 1680 MHz
[02:44] <dfm> there is this rs92-ngp (?) vesion, 1680mhz.
[02:44] <Darkside> oh that might be it
[02:45] <dfm> there was a rs92-agp/bgp.
[02:45] <Darkside> oh yes
[02:45] <Darkside> analog sondes
[02:46] <Darkside> i have one in a drawer
[02:46] <dfm> GMSK and 2 frames a second, not manchester, it used the them scrambling sequence as rs41.
[02:46] <Darkside> oh
[02:46] <dfm> so i didnt know.
[02:46] sumie-dh (~sumie-dh@78.108.102.220) left irc: Ping timeout: 245 seconds
[02:47] <dfm> figuring out the sequence took some time.
[02:48] <dfm> analog, you mean rs92-k..
[02:48] <Darkside> probably
[02:53] <Darkside> ill subit a PR for the changes i've made to dft_detect for all the debugging stuff sometime this weekend
[02:53] <Darkside> its not too invasive, just another array to store the maximum correlation scores
[02:53] <Darkside> and a command line flag to print them out at the end of processing
[02:54] <dfm> i have some changes, too.
[02:55] <dfm> small changes, little clean up, was just going through the code again.
[02:55] <Darkside> ok
[02:55] <Darkside> ill add mt debug stuff into those then :-)
[02:56] <dfm> maybe for auto_rx we have another version, lower thresholds.
[02:56] <Darkside> https://slexy.org/view/s2277VOn2q
[02:57] <dfm> I want to put the relevant decoders and tools in a new repo anyway.
[02:57] <Darkside> thats the output im producing, as a combination of the output from dft_detect, and running it across numerous files
[02:57] <Darkside> need to produce some plots
[02:58] <Darkside> pretty obvious why we were seeing the RS41 / M10 mis-identifications!
[02:58] <Darkside> those M10 correlation scores are way high
[02:59] <dfm> the rs41-preamble is like the m10-preamble.
[02:59] <Darkside> yeah i saw this comment in your code :P
[03:00] <dfm> since there is not so much more in the m10-header, the preamble is a bigger part.
[03:01] <dfm> after the preamble you could see the difference, the m10 has twice the baud rate.
[03:01] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[03:02] <dfm> but i hope, these 2nd passes are not needed. for imet i have it to tell the difference.
[03:02] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[03:03] <Darkside> i like the idea of the fft mask stuff
[03:04] <dfm> with narrower bandwidth it should look different. i know why you don't want it, but with wider bandwidth the rs41 and m10 are close together, and the header-bits-decoding is not so reliable at wider bandwidth and more noise.
[03:04] <Darkside> even just to determine the approximmate signal bandwidth, to set the fm demod correctly
[03:06] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Client Quit
[03:07] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[03:07] <dfm> ok, will go to sleep now.
[03:07] <Darkside> gnight!
[03:07] dfm (59cc992e@gateway/web/freenode/ip.89.204.153.46) left irc:
[03:08] tjq (uid339161@gateway/web/irccloud.com/x-znuzwhwxfoajlpyy) left irc: Quit: Connection closed for inactivity
[03:25] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[03:26] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[03:32] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[03:32] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[03:37] TimMc_ (~tim@unaffiliated/timmc/x-5757776) left irc: Quit: leaving
[03:39] TimMc_ (~tim@unaffiliated/timmc/x-5757776) joined #highaltitude.
[03:55] tweetBot (~nodebot@philcrump.co.uk) left irc: Remote host closed the connection
[03:55] tweetBot (~nodebot@philcrump.co.uk) joined #highaltitude.
[05:22] BrainDamage_ (~BrainDama@unaffiliated/braindamage) joined #highaltitude.
[05:24] BrainDamage (~BrainDama@unaffiliated/braindamage) left irc: Ping timeout: 255 seconds
[05:24] Nick change: BrainDamage_ -> BrainDamage
[06:22] BrainDamage_ (~BrainDama@unaffiliated/braindamage) joined #highaltitude.
[06:26] BrainDamage (~BrainDama@unaffiliated/braindamage) left irc: Ping timeout: 255 seconds
[06:26] Nick change: BrainDamage_ -> BrainDamage
[06:34] <TimMc_> bushfires everywhere!
[06:39] <TimMc_> Do BOM release radiosondes more frequently when weather is extreme?
[06:52] <Darkside> yep
[07:02] Kodar (~Kodar@93-139-209-121.adsl.net.t-com.hr) joined #highaltitude.
[07:08] <TimMc_> might go get the one in Epping in an hour
[07:17] Nick change: BitEvil -> SpeedEvil
[07:30] <SpacenearUS> New position from 03SP9UOB-P28 after 0312 hours silence - 12https://tracker.habhub.org/#!qm=All&q=SP9UOB-P28
[07:45] <SpacenearUS> New position from 03SP9UOB after 03a day silence - 12https://tracker.habhub.org/#!qm=All&q=SP9UOB
[07:46] hyde00001 (~hyde00001@cpc69050-oxfd25-2-0-cust745.4-3.cable.virginm.net) joined #highaltitude.
[07:46] <hyde00001> !flights
[07:46] <SpacenearUS> 03hyde00001: Current flights: 03YO3ICT 10(4ee4), 03PICO-32 144.251 MHz CTSTIA32/1000 10(33b0)
[07:47] <SpacenearUS> New vehicle on the map: 03Df9ik_chase - 12https://tracker.habhub.org/#!qm=All&q=Df9ik_chase
[07:47] Lahti2 (bc4354ca@gateway/web/freenode/ip.188.67.84.202) joined #highaltitude.
[08:07] YO9GJX (~YO9GJX@109.100.112.75) left irc: Remote host closed the connection
[08:22] hyde00001 (hyde00001@cpc69050-oxfd25-2-0-cust745.4-3.cable.virginm.net) left #highaltitude.
[08:36] <SpacenearUS> New position from 03SP9UOB-P32 after 03a day silence - 12https://tracker.habhub.org/#!qm=All&q=SP9UOB-P32
[08:55] <SpacenearUS> New position from 03BSS18 after 0316 hours silence - 12https://tracker.habhub.org/#!qm=All&q=BSS18
[09:01] <SpacenearUS> New vehicle on the map: 03VK3FTMC_chase - 12https://tracker.habhub.org/#!qm=All&q=VK3FTMC_chase
[09:01] <SpacenearUS> New position from 03SP9UOB-P33 after 0313 hours silence - 12https://tracker.habhub.org/#!qm=All&q=SP9UOB-P33
[09:11] <SpacenearUS> New position from 03YO3ICT after 0317 hours silence - 12https://tracker.habhub.org/#!qm=All&q=YO3ICT
[09:18] hyde00001 (~hyde00001@cpc69050-oxfd25-2-0-cust745.4-3.cable.virginm.net) joined #highaltitude.
[09:19] M0JSN (~jonsowman@46.101.80.104) joined #highaltitude.
[09:19] M0JSN (~jonsowman@46.101.80.104) left irc: Client Quit
[09:20] jonsowman (sid155658@gateway/web/irccloud.com/x-ssuwhejfujhqrpta) left irc:
[09:21] jonsowman (~jonsowman@46.101.80.104) joined #highaltitude.
[09:23] <hyde00001> I'm thinking of making a payload displaying some rolling text - has anyone successfully used an oLED type display at HAB altitudes? Anyone know if there is any intrinsic reason (temp/pressure...) why one wouldn't behave?
[09:25] jonsowman (~jonsowman@46.101.80.104) left irc: Client Quit
[09:25] jonsowman (~jonsowman@46.101.80.104) joined #highaltitude.
[09:40] <daveake> http://fab4space.000webhostapp.com/language/en/
[09:41] <daveake> He used to post he but not seen him for a while
[09:46] <hyde00001> daveake - cheers. They work then... (though if honest I didn't realise how flickery the display could be if filmed)
[09:46] <SA6BSS-Mike> !whereis BSS18
[09:46] <SpacenearUS> 03SA6BSS-Mike: 03BSS18 was over 0339.29167,-8.83333 at 0311260 meters about 0311 minutes ago
[09:50] hyde00001 (hyde00001@cpc69050-oxfd25-2-0-cust745.4-3.cable.virginm.net) left #highaltitude.
[09:54] <mwheeler> Did you get it TimMc_ ?
[09:54] PE2BZ (~pe2bz@162-066-045-062.dynamic.caiway.nl) joined #highaltitude.
[09:54] <mwheeler> it looked fenced off on gmaps
[09:58] sumie-dh (~sumie-dh@78.108.102.220) joined #highaltitude.
[10:01] Viproz (~Viproz@unaffiliated/viproz) joined #highaltitude.
[10:06] <Viproz> Darkside, were you able to test some more today ?
[10:06] <SpacenearUS> 03PE0SAT: Here you go: 12https://ukhas.org.uk/spacenearus_irc_bot
[10:07] <Darkside> Viproz: yep.
[10:07] <PE0SAT> !flights
[10:07] <SpacenearUS> 03PE0SAT: Current flights: 03YO3ICT 10(4ee4), 03PICO-32 144.251 MHz CTSTIA32/1000 10(33b0)
[10:07] <Darkside> Viproz: https://github.com/darksidelemm/radiosonde_auto_rx/blob/testing/auto_rx/test/notes/dft_detect_optimization.md
[10:07] <Darkside> and writing up somethign now regarding the rs_detect to dft_detect change
[10:09] <PB0AHX-Herman> PE0SAT, Hoi Jan
[10:10] <Viproz> nice work, with graphs and everything
[10:10] <Darkside> yup!
[10:10] PA-Balloon (05cedd43@gateway/web/freenode/ip.5.206.221.67) joined #highaltitude.
[10:10] <Darkside> more graphs to come
[10:12] <Viproz> While in hammac I was thinking, is dft_detect returning as soon as it detects a RS above the given threshold ?
[10:12] <Darkside> it is
[10:13] <Viproz> one important improvement we could then do is to modify it to confirm x times then, if we just accept that it is a bit slower
[10:13] <Darkside> possibly, yes
[10:13] <Darkside> but with appropriate thresholding false detections can be minimised
[10:13] <Darkside> hence my testing with noise
[10:14] <Darkside> as it is, the thresholds have to be set higher than the noise correlation score, otherwise you get mis-detections
[10:14] <Viproz> though I don't know if when it detects a M10 it's going to detect it a few times in the sample or just once
[10:14] <PE0SAT> PB0AHX-Herman: Hallo Herman
[10:14] <Darkside> yes, that is an issue with the M10s, due to their sporadic transmissions
[10:14] <Darkside> hence i think leaving it as it is, is probably OK
[10:15] <PE0SAT> PB0AHX-Herman: Zit je ook op HABNL?
[10:15] <PB0AHX-Herman> PE0SAT, nee heb ik nog niet aan staan moment ik kom er aan
[10:17] ok1cdj (4decd062@gateway/web/freenode/ip.77.236.208.98) joined #highaltitude.
[10:17] <ok1cdj> hello all
[10:17] <PB0AHX-Herman> PE0SAT, nu wel Jan
[10:25] <ok1cdj> can anyone aprove my flight for BRNO Picoballon challenge on monday 4th. CDJ3, thank you
[10:25] <PE2BZ> ok1cdj you ask for approvement in #habhub please ? There are the admins :-)
[10:26] <ok1cdj> pe2bz, ok thanks..
[10:31] <PE2BZ> SA6BSS-Mike indeed a bit ¨special¨ that 3 payloads, from different dates and launch locations, end up this close to each other !
[10:38] <Viproz> Darkside, the LNA you sent yesterday filters out all of the HAB frequencies, is it really usefull to do a bandpass compared to a high pass filter ?
[10:40] <Darkside> Viproz: depends what you have around you
[10:42] YO9GJX (~YO9GJX@109.100.112.75) joined #highaltitude.
[10:42] <TimMc_> construction zone :(
[10:43] <Viproz> I actually have a lot of QRM in the bandwidth, I don't know if they are some frequency bleeding out or real signals
[10:43] <Viproz> https://imgur.com/a/jo0Y2QI
[10:44] <Darkside> interesting
[10:44] <Darkside> could be interemod
[10:44] <Darkside> could be real signals... hard to tell
[10:45] <Viproz> the ones in the middle really look like thermometers
[10:45] <Darkside> what rtlsdr is this
[10:46] <Viproz> NooElec NESDR SMArt TCX0
[10:46] ok1cdj (4decd062@gateway/web/freenode/ip.77.236.208.98) left irc: Ping timeout: 256 seconds
[10:46] <Darkside> R820T2 tuner?
[10:46] <Viproz> yep
[10:47] <russss> you can try https://github.com/merbanan/rtl_433 and see what you can receive
[10:47] <Viproz> https://www.amazon.fr/gp/product/B01GDN1T4S/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
[10:47] <Darkside> that would be an interesting test actually
[10:47] <Darkside> run rtl_433 on that frequency and see if it is something like a thermometer
[10:47] <Viproz> russss, thanks I'll give it a try
[10:49] <russss> I think there are more tyre pressure sensors cropping up on 433 these days
[10:49] <russss> which are naturally hard to localise...
[10:51] sumie-dh (~sumie-dh@78.108.102.220) left irc: Ping timeout: 268 seconds
[10:53] <TimMc_> Something was making a tone on 402.650 near Costco in Epping where an rs41 landed (unable to get from constructtion zone)
[10:54] <russss> cranes are also (terrifyingly) a thing on the ISM bands
[10:55] <Viproz> rtl_433 -f 401650000, just this right ? I'm not getting anythin
[10:57] <Darkside> probably means it doesnt know what it is
[10:57] <Darkside> rtl_433 suports a lot of stuff, but not evertyhing
[10:58] <Viproz> yeah it's working on 433, it's awesome I don't need any temperature sensors I can just use the ones in the wild :p
[11:00] <Darkside> yeah same here :P
[11:02] <Viproz> https://imgur.com/a/jo0Y2QI bottom pic, there is a lot of activity but it doesn't look exactly the same as on the 402 band
[11:03] <Viproz> but yeah given the clipping and overloading at 433 MHz a bandpass would definetely seem useful
[11:05] <PE2BZ> Viproz I think the signals around 401.600 - 401.650 are real signals. That band is also allowed for ¨medical appliances¨ in the EU
[11:05] <PE2BZ> http://websdr.pe2bz.nl:8080/2019-03-02_05-12-44_waterfall.png
[11:06] <PE2BZ> Around 22:30 on 401.625 a lot of activity, which ends around midnight and starts again in the morning.
[11:08] chris_99 (uid26561@gateway/web/irccloud.com/x-iojwgixptcncobps) joined #highaltitude.
[11:10] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) joined #highaltitude.
[11:12] <dfm> darkside: this bit-error-count i was talking about. Instead of having a limit, for detection it maybe better just to compare, all detected radiosondes, which one has the lowest number of herrs.
[11:12] <dfm> Up to maybe 8.
[11:12] <Darkside> maybe?
[11:13] <Darkside> thing is, right now, we are detecting down *below* the point at which decoding is possible anyway
[11:13] <Darkside> so... its pretty good :-)
[11:13] <dfm> Decoding the whole frame is more difficult then just decoding a few header bits.
[11:13] <Darkside> dft_detect is pretty amazing
[11:13] <Darkside> yeah of course
[11:14] <Darkside> tbh we should probably *raise* the threshold slightly so that the detection performance matches the decode performance
[11:14] <Darkside> maybe
[11:14] <dfm> because integrating is kind of matching, just rectangular pulse shape. for known bits it should be close enough-
[11:14] <dfm> i will try.
[11:14] <Darkside> its all fine right now
[11:15] <dfm> for detecting different radiosondes i didn't think about it, it was for checking a particular type.
[11:15] <dfm> just because i'm testing dft_detect myself.
[11:15] <dfm> there is one thing, that a header could be missed.
[11:15] <Darkside> did you see the analysis on thresholds? https://github.com/darksidelemm/radiosonde_auto_rx/blob/testing/auto_rx/test/notes/dft_detect_optimization.md
[11:16] <dfm> so probably it will be detected the next frame.
[11:16] <dfm> just took a quick look, nice graphs.
[11:16] <dfm> just to explain the correlation:
[11:17] <dfm> to speed up, the fourier transforms are multiplied.
[11:18] <dfm> so to compare, the vectors should be normalized.
[11:18] <dfm> the match/header-vector has norm 1.
[11:19] <Darkside> i'm not really comparing the scores type-to-type
[11:19] <dfm> but to avoid normalizing every vector in the sliding K-window, it is assumed that the norms are constant.
[11:20] <dfm> and the vector with the highest scalar produkt with the match vector is then normalized at the end.
[11:21] <dfm> Only if the signal is varying in amplitude, it could happen that a peak is not detected as high as it actually is.
[11:21] <Darkside> yep, and that definitely happens
[11:21] <Darkside> at the moment auto_rx runs the detect process for 5 seconds
[11:21] <dfm> and the rs41-noise/pause has more amplitude in fm as well.
[11:21] <Darkside> perhaps that isnt enough?
[11:21] <dfm> but normally, if the K-window is not to big, that is no problem.
[11:22] <dfm> the relative peak is then normalized, and the normalized peak has the right value.
[11:23] <dfm> in a few thousend test files i did encounter this only a few times, i think the c34-samples fluctuated.
[11:23] <Darkside> i've seen it with spinning sondes after burst
[11:23] <Darkside> but by that point you've ideally already locked onto the signal anyway
[11:24] <dfm> Yes, or if it is right above you, maybe, but i think that is not really a problem.
[11:25] <mwheeler> listening to sondes in USB you can audibly hear when they burst :P
[11:25] <Darkside> yeah
[11:25] <dfm> The few examples did miss the maybe one header.
[11:25] <Darkside> yeah not an issue
[11:25] <Darkside> i mean, it would be nice to get all packets, but if we miss a few, its not a huge issue
[11:25] <dfm> but still, want to adjust the windows a little bit in the code.
[11:25] <Darkside> ok
[11:26] <dfm> HIf you would normalize at every point, the fourier transform would be rather pointless.
[11:28] <dfm> end it is not that a sonde would be false positive. a peak could slip through, because some other region has a sudden burst of amplitude such the relative score would be higher. but this peak would be normalized then to a lower value, under the threshold.
[11:28] <dfm> And I think the K-window is 1 sample short.. ;)
[11:29] <Darkside> well, let me know when you change things, and I'll test and integrate :-)
[11:29] <Darkside> the aim of auto_rx - track ALL the radiosonde
[11:29] <dfm> Today probably.
[11:29] <dfm> lms6 iq samples
[11:30] <dfm> PE2BZ records the LMS6 from time to time, he provided the IQ recording that I have on youtube.
[11:30] <Darkside> oh interesting!
[11:31] <dfm> It didn't have much bandwidth, but maybe he has one with more.
[11:31] <Darkside> i guess if we just add the JSON Output stuff to the LMS6, we could add support for it in and see what happens
[11:31] <Darkside> we might see more show up
[11:31] <dfm> I would like to see it more isolated to get an impression of SNR.
[11:32] <dfm> Now with viterbi (reed-solomon is not doing much here right now) the performance seems to be quite good.
[11:33] Action: PE2BZ bought an LMS6 from the UK last year. Power it up with 9 Volt and it might still be working :-)
[11:33] <dfm> In Europe they fly occassionally south of England.
[11:33] <Darkside> ooh
[11:33] <PE2BZ> But ¨on air¨ I did not receive any LMS6 for the last 4 months
[11:33] <dfm> Ok, right, and he sent me radiosonde (thanks)!
[11:33] <Darkside> PE2BZ: if youcan power it up and get us a good recording that would be good
[11:34] <dfm> I didn't want to break the seal! ;))
[11:34] <dfm> Maybe I should do this, somewhere outside.
[11:34] <PE2BZ> Mine is all in parts :-) I even re-used the batteries for RS41 flights
[11:34] <Darkside> PE2BZ: can you make it work again?
[11:34] <PE2BZ> But should still be operational :-)
[11:34] <dfm> Completely forgot about it.
[11:35] <PE2BZ> Let me see.... 9 Volts DC ?
[11:35] <PE2BZ> dfm you´re from DL ?
[11:35] <dfm> interesting to see, it is even bigger then m10
[11:35] <Darkside> PE2BZ: an IQ recording with the sonde signal nice and strong (use SDR# or GQRX to figure out gain), and with teh signa right in the centre
[11:35] <Darkside> a few minutes of recording would be enough
[11:35] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[11:36] <dfm> So maybe this lmsX is really a new model.
[11:37] <Viproz> PE2BZ, Okay thanks might be able to decode some stuff then !
[11:37] <Viproz> I gotta go..
[11:38] <dfm> DL?
[11:38] <PE2BZ> Germany
[11:38] <dfm> right
[11:38] <PE2BZ> Deutschland :-)
[11:38] <dfm> ok
[11:38] <PE2BZ> Darkside would gps lock be needed for the recording ?
[11:38] <Darkside> PE2BZ: it would be preferred
[11:40] <dfm> since i didn't open it yes.
[11:42] <dfm> i think there is an 8bit stm mcu inside? (seen on pictures) time for an update.
[11:42] <mwheeler> Darkside: did Melbourne forget to launch ?
[11:43] <Darkside> mwheeler: dunno lol
[11:43] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 244 seconds
[11:44] <Darkside> https://github.com/darksidelemm/radiosonde_auto_rx/blob/testing/auto_rx/test/notes/2019-03-01_detector_change.md
[11:45] Action: PE2BZ is awaiting GPS lock
[11:47] <PE2BZ> https://photos.app.goo.gl/kfSmM1ikBGsgLY4h8
[11:47] <PE2BZ> Could save you from opening the box :-)
[11:47] <dfm> I it so nicely packed...
[11:47] <Darkside> wow, huge PCB
[11:48] <dfm> it is not so different from Mk2a, I think.
[11:49] <Darkside> it doesnt look like they designed it to be lightweight :P
[11:49] <dfm> no, it is old school.
[11:50] <Darkside> yeah it looks it!
[11:50] <dfm> even imet-4 is no compact and modern.
[11:50] <Darkside> PE2BZ: whats the model of the main microcontroller? (the TQFP)
[11:50] <Darkside> yeah the imet4 looks nice - though its still using inefficient AFSK!
[11:50] <dfm> i think nowadays it is not so difficult to produce a lightweight compact radiosonde.
[11:50] <Darkside> the DFM17 looks *really* ice
[11:50] <Darkside> nice*
[11:50] <Darkside> would like to get my hands on a few of those!
[11:51] <dfm> yes, thats odd, probably compatibility-
[11:51] <SpacenearUS> New vehicle on the map: 03ND6W-5 - 12https://tracker.habhub.org/#!qm=All&q=ND6W-5
[11:51] <Darkside> dfm: the imet ground station is interesting - they use an Icom IC-R20 for RX
[11:51] <PE2BZ> (8007223) [ 823] Sa (11:51:42.000) lat: 51.991567° lon: 4.198743° alt: 51.23m vH: 0.1m/s D: 257.8° vV: -0.0m/s
[11:51] <PE2BZ> (8007223) [ 824] Sa (11:51:43.000) lat: 51.991566° lon: 4.198743° alt: 51.05m vH: 0.0m/s D: 228.7° vV: -0.0m/s
[11:51] <PE2BZ> (8007223) [ 825] Sa (11:51:44.000) lat: 51.991565° lon: 4.198744° alt: 50.90m vH: 0.1m/s D: 234.6° vV: 0.0m/s
[11:51] <PE2BZ> (8007223) [ 826] Sa (11:51:45.000) lat: 51.991563° lon: 4.198740° alt: 50.70m vH: 0.1m/s D: 260.4° vV: 0.0m/s
[11:51] <Darkside> at least, the portable station i have seen does
[11:52] <Darkside> PE2BZ: does that serial number (8007223) match whats on the box?
[11:52] <Darkside> (if you have it)
[11:53] <dfm> looks like the one on the photo
[11:53] <Darkside> oh i missed that
[11:53] <Darkside> now i see it
[11:53] <PE2BZ> I have the box :-) but no labels attached anymore ;-)
[11:54] <dfm> first i wasn't sure, how serial number is in the first bytes of the frame.
[11:54] <dfm> they all seem to start with 8....
[11:54] <PE2BZ> 180 mA current from 9.1 Volt DC
[11:54] <PE2BZ> If the recording is finished I will take a look at the chip
[11:55] <Darkside> about the same as a DFM09
[11:55] <Darkside> well, total power draw
[11:55] <Darkside> DFM09 uses 6V
[11:56] <PE2BZ> https://www.dropbox.com/s/rpofrdvo6d2ota0/02-Mar-2019%20125214.281%20400.262MHz%20000.wav?dl=0
[11:56] <Darkside> oh
[11:56] <dfm> the lightweight radiosondes are more difficult to predict after burst, I think.
[11:56] <Darkside> PE2BZ: we need an IQ recording
[11:56] <PE2BZ> 400.262 MHz frequency recorded as IQ data
[11:57] <Darkside> oh
[11:57] <Darkside> what bandwidth?
[11:57] <Darkside> around 96 kHz would make thigns easier for me :P
[11:57] <PE2BZ> 550 kHz (smalles the Pluto can run on SDR Console
[11:57] <Darkside> oh!
[11:57] <Darkside> ok
[11:57] <Darkside> filename is misleading
[11:58] ensign (~ensign@2001:41d0:8:d711::1) left irc: K-Lined
[11:58] <PE2BZ> You need IQ to understand that :-)
[11:59] <dfm> don't know how much the lms6 is drifting.
[12:00] <Darkside> looks liek a regular crystal
[12:00] <mwheeler> I guess the answer to "I wonder if we should fetch tonights sonde" is no
[12:01] <mwheeler> considering I'd have to drive to ADL it seems :P
[12:01] <Darkside> haha
[12:01] <Darkside> you knoy you want to :P
[12:01] <Darkside> know*
[12:02] <PE2BZ> Darkside 72f324j6t6 ?
[12:02] ensign (~ensign@2001:41d0:8:d711::1) joined #highaltitude.
[12:02] <Darkside> PE2BZ: bless you
[12:03] <Darkside> :P
[12:03] PA-Balloon (05cedd43@gateway/web/freenode/ip.5.206.221.67) left irc: Quit: Page closed
[12:03] <Darkside> i wonder what GPS chipset its using
[12:03] <dfm> didn't they use trimble?
[12:03] <PE2BZ> Tomorrow I expect to have my room temperature reported ;-)
[12:04] <Darkside> dfm: dunno, its under a metal can :P
[12:04] <PE2BZ> Do you really want to see it naked ?Come on guys ;-)
[12:04] tjq (uid339161@gateway/web/irccloud.com/x-rkgfjlfkddtuwmcs) joined #highaltitude.
[12:05] <dfm> oh now... temperature. i don't like this analog readings... ;)
[12:05] <PE2BZ> I know ;-) You hava also pressure issues ?
[12:06] <dfm> the sensor: is humidity the plate, in the smaller sensor temperatur?
[12:06] <Darkside> hrm, so that looks like hard-keyed FSK
[12:06] <dfm> temperature is easiest, then humidity, then pressure...
[12:06] <Darkside> no nice pulse shaping
[12:06] <Darkside> look at all those sidebands
[12:06] <PE2BZ> Trimble 58048-10 with serial S/N 13313391
[12:07] <dfm> to much calibration. i wonder how my smartphone is doing this.
[12:07] <Darkside> PE2BZ: how much do you trust your plutoSDRs frequency calibration
[12:08] <Darkside> i see the centre is on 400.262 MHz... im just wondering how much of that is from your plutoSDR, and how much is the sonde
[12:09] <PE2BZ> Quite easy to answer :-) I monitored the same transmission on the websdr (2 km distance) and there it was at 400.263.9 and that one is 1.9 KHz off :-)
[12:09] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Quit: Page closed
[12:09] <Darkside> ouch
[12:10] <Darkside> memories of the old analog RS92s that drifted all over the place
[12:10] <PE2BZ> The pluto is calibrated, to the repeater in central Holland, 430.125 MHz
[12:11] <dfm> I think thats Trimble Copernicus (II), like former imet and M10.
[12:11] <Darkside> going to make doing automatic frequency detection a bit more of a pain
[12:12] <PE2BZ> dfm I don´t know about the sensors. I know that the large metal one on the end of the white whire which runs parallel to the plastic sensor cup is used to put the LMS6 back on the wall, using a screw :-)
[12:12] <dfm> Don't know if there is a successor
[12:12] <Darkside> currently i assume everything is on a 10 khz step, which is true for the DFM, RS92, RS41, and M10
[12:12] <Darkside> but it soudns like the LMS6 is going to break that
[12:12] <Darkside> hopefully the LMSX is better :-)
[12:12] <PE2BZ> Yes it is !
[12:12] <dfm> lms6 has only a few frequencies.
[12:13] <Darkside> oh
[12:13] <Darkside> hmm
[12:13] <dfm> imet has only 5 or so.
[12:13] <PE2BZ> 16 listed, 4 dipswitches
[12:13] <Darkside> i guess as a workaround people who know they have LMS's in the area can just put frequencies in the whitelist or greylist
[12:13] <dfm> it is written on the envelope.
[12:13] <Darkside> and bypass the peak detection step entirely
[12:14] <PE2BZ> Darkside I added the ¨frequency select¨ label to the LMS6 album
[12:14] <dfm> 400.25, 400.625, 401.00, 401.375, ... 375kHz steps.
[12:15] <PE2BZ> So this one is at least 12 kHz off, but all UK LMS6 sondes I have received sofar where on 400.260
[12:15] <Darkside> 12 khz!
[12:15] <Darkside> jeez
[12:15] <dfm> 400.25 is the "factory setting" i guess.
[12:16] <dfm> rs41 is on 402mhz, i think
[12:16] <dfm> dfm09 on 402.87?
[12:19] <dfm> darkside: did you look at scan/scan_fft_pow.c ?
[12:19] <dfm> it is a first quick hack, maybe a bit more
[12:19] OZ1SKY_Brian (~Brian@2-104-129-194-cable.dk.customer.tdc.net) joined #highaltitude.
[12:20] <dfm> it detects the peaks quite good, though m10 is no corrected. and bandwidth estimate is missing.
[12:20] <Darkside> dfm: yeah, i had a brief look
[12:20] <dfm> there are different ways for peak detection, just tried a few.
[12:21] <Darkside> i was intending to have a go writing my own in the end
[12:21] <Darkside> just need to record a few seconds of IQ on a few frequencies and combine
[12:21] <Darkside> in EU need to cover 400-406 MHz
[12:22] <dfm> if you have i fixed bandwidth, it is easier, since there are a few parameters to calibrate. choosing the right bin size for resolution, then a bit of filtering.
[12:23] <dfm> and discarding narrow peaks/signals.
[12:24] <Darkside> yeah now thats a good improvement
[12:24] <Darkside> get rid of spurs
[12:24] <Darkside> though have to be careful with FFT length and M10s i guess
[12:27] <dfm> try it yourself, this way you get most ideas.
[12:27] <Darkside> yeah
[12:27] <Darkside> i still like the idea of the FFT mask correlation stuff
[12:28] <dfm> i have to come back to this scan tool.
[12:28] <Darkside> but im not sure how it would go at weak signals
[12:28] <dfm> yes, the correlation.
[12:28] <Darkside> another cooler option would be to go full machine learning on the problem
[12:28] <dfm> with very strong signals i'm not sure.
[12:28] <Darkside> capture 20 seconds, make a spectrogram, and throw computer vision techniques at the problem
[12:28] <dfm> and how much integration time and filtering.
[12:30] <dfm> i still think automated wire tapping knows how to do it.
[12:36] <Darkside> bleh 11 pm and still 33 degrees here
[12:36] <dfm> darkside, i think DFM has 20kHz steps, .01, .03, ...
[12:36] <Darkside> dfm: still on a 10 khz boundary
[12:37] <Darkside> so good enough for me :P
[12:37] <dfm> and then it drifts...
[12:37] <Darkside> yeah
[12:37] <Darkside> thats the interesting part
[12:37] <Darkside> i wondering by how much
[12:37] <Darkside> because i can easily quantify the degradation in RX performance due to drift
[12:38] <dfm> the one i see here often, starts at 402.87, goes down to 402.864 maybe, DFM-09, like DFM-06.
[12:38] <Darkside> ok thats not so good
[12:39] <Darkside> this is where a demod that looks at a wider bandwidth and does frequency estimation to find the tones would perform better for sure
[12:39] <dfm> but just before landing it is back on 402.87 again
[12:39] <dfm> sure.
[12:39] <Darkside> either that or a feedback loop to re-tune the receiver - assuming you can lock onto it at all in the first place
[12:40] <dfm> or a lowpass filter included in the demod, after dc-correction.
[12:40] <dfm> how long is auto_rx decoding a signal, how does it "lock"
[12:41] <Darkside> once a signal is detected, a demodulator is started up on that frequency
[12:41] <Darkside> and it will run until a tieout
[12:41] <Darkside> timeout*
[12:41] <Darkside> i.e. no packets after X seconds
[12:41] <Darkside> the X is customizable. default is 3 minutes
[12:41] <dfm> so when does it rescan or look for another radiosonde?
[12:42] <Darkside> when it doesnt get any packets from the sonde for that timeout period
[12:42] <Darkside> so it is intended to receive a single sonde, and stay tracking it for the entire flight
[12:42] <dfm> ok, 3 minutes, maybe thats enough for dfm. but when it is cold it really drifts fast, almost like doppler..
[12:42] <dfm> so not LEO
[12:42] <Darkside> yeah, hence the different style RX
[12:43] <dfm> but the frequency tracking is on the TODO list.
[12:44] <dfm> At least I want to see what easy fixes there are and the limitations.
[12:44] <Darkside> yup
[12:44] <Darkside> i know that i can put a RS41 signal anywhere within the passband of fsk_demod and get the same decode performance as with a tightly-filtered FM demod around it
[12:44] <dfm> first i do the changes for dft_detect and hope it is not worse than before.
[12:45] <dfm> But still it filters somewhere.
[12:45] <Darkside> oh of course
[12:46] <Darkside> but its doing that *after* it estimates the tone locations
[12:47] <dfm> With the iq-input, at least I want to let a wider unfiltered bandwidth in for frequency estimate, then either a iq-demodulation (needs some improvement), or filtering and fm-demodulation in the decoder.
[12:48] <dfm> the fm-demodulation is rather simple, only speed-optimization is an issue.
[12:49] <dfm> but for small deviations, it is not a problem.
[12:49] <dfm> yes, filtering after frequency correction.
[12:50] <dfm> thats why i want to receiver the unfiltered (lets say 48kHz) iq-signal in.
[12:50] <dfm> For small frequency offset it works. I didn't think about larger offsets yet.
[12:50] <dfm> and m10 needs a little different treatment.
[12:51] <Darkside> 48 khz is fairly nice with the RTLSDR
[12:51] <Darkside> as you can set it to almost arbitrary sample rates
[12:51] <Darkside> so could et to 480 khz and decimate by 10, which is easy on the CPU
[12:52] <dfm> and for 4800 baud it is a round number.
[12:52] <Darkside> yeah
[12:52] <Darkside> gets weird with the M10 and DFM though
[12:52] <Darkside> 9614...
[12:52] <Darkside> what a pain
[12:52] <dfm> the (new?) lmsX has 4797?
[12:52] <Darkside> lol
[12:52] <Darkside> could they just not be bothered
[12:53] <Darkside> 'bugger it, well fix it on the decoder'
[12:53] <dfm> samples are 48023 long with 48000 sampling rate.
[12:54] <dfm> if i would try decimation, then by 2, halfband filter
[12:55] <dfm> So I wuold select 48k or 60k if-samplerate, then multiply by 32 for baseband rtlsdr frequency.
[12:55] <dfm> like sdr#
[12:55] <Darkside> hmm
[12:56] <Darkside> 1920khz might be a bit much for a poor little pi
[12:56] <dfm> but the csdr bandpass fft filter seems to work
[12:56] <Darkside> 16 would be better
[12:56] <Darkside> 960 khz
[12:56] <dfm> decimation i mean
[12:56] <dfm> if it is not to narrow for scanning.
[12:56] <dfm> but otherwise, yes, of course.
[12:57] <dfm> ok, on a raspi, don't know if airspy 6 mhz works.
[12:58] <Darkside> nooop
[12:58] <Darkside> nope
[12:58] <dfm> and 3 mhz?
[12:58] <Darkside> maybe just
[12:58] <dfm> airspy mini?
[12:58] <Darkside> RTLSDR is the target RX at the moment
[12:59] <dfm> did you test this, what was the name
[12:59] <dfm> rx-tools
[12:59] <Darkside> yeah its buddy as hell
[12:59] <Darkside> buggy*
[13:00] <dfm> oh
[13:00] <dfm> i thought, it only combine rtl_sdr and the airspy_tools.
[13:00] <Darkside> its basically the rtl-sdr tools, but with a hacked on soapySDR backend
[13:01] <dfm> i tested scanning only with airspy iq-recordings from sdr# and sdr-console.
[13:02] <dfm> i guess, the airspy command line tool provides similar data.
[13:03] <Darkside> theres no equivalent of airspy_fm
[13:03] <Darkside> rtl_fm i mean
[13:03] <Darkside> or rtl_power
[13:03] <Darkside> but if the aim is to replace those tools, then thats fine
[13:03] <dfm> thats why i tried my own scan tool, needs only the iq-data.
[13:03] <Darkside> i guess it would be better if the scan tool called the various utility instead of accepting it from stdin?
[13:03] <Darkside> then you could run it multiple times
[13:03] <Darkside> at different frequencies
[13:04] <dfm> ultimately you could put all the tools together, i guess.
[13:04] <dfm> but still better then rtl_power
[13:05] <Darkside> yes
[13:05] <Darkside> i used rtl_power because it did the job, and did it easily
[13:05] <dfm> yes, i did this too.
[13:06] <dfm> but fft is not so difficult.
[13:06] <dfm> it more challanging part is preak-detection.
[13:06] <dfm> peak-detection
[13:07] <superkuh> I was delighted to see that part was in perl.
[13:07] <dfm> and if you have to do it anyway, why not do the fft first.
[13:07] <Darkside> superkuh: dfm's version is :P
[13:07] <Darkside> mine is in python :P
[13:07] <superkuh> Oh, okay.
[13:07] <dfm> oh, only the very first script.
[13:08] <dfm> was only an simple example.
[13:08] <superkuh> I was being serious. So much SDR stuff is in python. It's nice to run into something I know.
[13:09] <Darkside> i dont have enough beard to use perl
[13:09] <dfm> i like numpy. but have to admit, i'm more familiar with c, so perl is close.
[13:12] <dfm> in c you often reinvent things. it is not always running better, but maybe you learn more, make the same mistakes, ...
[13:12] <Darkside> theres always libraris like fftw3..
[13:13] <dfm> i know. but as a said before. primary goal is to learn, how it works in principle. optimization is second for me.
[13:13] <Darkside> http://rfhead.net/sondes/plots/per_20190302.png
[13:14] <dfm> is this with --ecc? looks like for rs41, but rs92?
[13:14] <Darkside> yeah ecc is on
[13:14] <Darkside> though im not sure i have the filter width optimized for the RS92
[13:15] <dfm> rs92 is like rs41, not much difference.
[13:16] <dfm> and dfm09 bandwidth?
[13:16] <Darkside> 20k sample rate on rtl_fm
[13:16] <Darkside> exactly what filter bandwidth that corresponds to im still not sure
[13:16] <Darkside> i suspect possibly half that
[13:16] <dfm> this graph is not normalizing the baud rate.
[13:17] <Darkside> its meant to be....
[13:17] <Darkside> i suspect the performance differences are due to the non-optimal filtering
[13:18] <dfm> if i use 9.6 kHz bandwidth for rs41, dfm, dfm is better, the lower bitrate and manchester beats reed-solomon.
[13:18] <dfm> but with eb/no you mean "normalized" bitrate?
[13:19] <Darkside> yeah, as i said, i probably have the filter not set ideally
[13:19] <Darkside> yes
[13:19] <Darkside> SNR-per-bit
[13:19] <Darkside> assuming all my eb/n0 calculations are correct!
[13:19] <dfm> ok, then the reed-solomon should be better then hamming.
[13:20] <Darkside> i calculate the amount of noise to add based on the variance of the radiosonde signal (limited to when just packets are transitter)
[13:21] <Darkside> and then i calculate the amount of noise to add based on sample rate and baud rate
[13:21] <Darkside> https://github.com/darksidelemm/radiosonde_auto_rx/blob/testing/auto_rx/test/generate_lowsnr.py#L60
[13:21] <dfm> rs92 has manchester, that is a bit better then rs41. but the standard rs41-frames have 2 codewords, rs92 only one.
[13:21] <Darkside> i figured normalising it all to SNR -per-bit was a better way of looking at performance
[13:21] <Darkside> it is the typical way of evaluating modems after all
[13:22] <Darkside> and then we can compare performance to theoretical possible FSK demod performance
[13:22] <dfm> yes, the baudrate should be factored out.
[13:22] <Darkside> when we hit theoretical performance, no point trying to optimize any more :-)
[13:22] <Darkside> Mr Shannon might have something to say about things at that point
[13:24] <dfm> there is this weissman score in "silicon valley", where they beat the theoretical limit... ;)
[13:25] <Darkside> going to do a run with all ECC turned off and see what happens
[13:25] <dfm> ecc was helping me not to think so much about better demodulation...
[13:28] <Darkside> hmm interesting... no change in DFM performance with ECC on or off?!
[13:28] <dfm> M10 and even more DFM have a higher modulation index.
[13:28] <Darkside> thats odd
[13:29] <dfm> How do you see, if a dfm-frame is decoded correctly?
[13:30] <Darkside> so im running with ../dfm09ecc -vv --json --dist --auto
[13:31] <Darkside> and checking for the json outputs
[13:31] <Darkside> counting the number of json outputs
[13:31] <Darkside> perhaps thats not right way?
[13:31] <dfm> The dfm-decoder outputs frames even if there are errors.
[13:31] <Darkside> ok thats going to make this difficult then!
[13:31] <Darkside> :P
[13:31] <dfm> with --dist, --ecc is automatically turned on.
[13:31] <Darkside> ahhh
[13:31] <dfm> You can view the raw output.
[13:32] <Darkside> what would be the best way to check a frame is corect?
[13:32] <Darkside> given theres no CRC option
[13:32] <dfm> i included it somehow in --dist, i count the bit-errors.
[13:33] <dfm> try -R output
[13:34] <dfm> dfm09dm_dft --ecc -vv -R --auto
[13:35] <Darkside> hmm
[13:36] <dfm> (0) means no bits corrected. (F) means, no correction possible.
[13:36] <Darkside> but is there a way to just count the number of valid frames?
[13:37] <Darkside> or is this what you mean
[13:37] <dfm> In one block it correct on bit per nibble+parity, though only the data-nibble is displays.
[13:37] <Darkside> you can see the ECC working hard at 10dB Eb/N0!
[13:37] <Darkside> 000002B602040 (5) 8608C20007D01 (2) EB4E099A00042 (0) 52AAD82102AC3 (6) 000026B900004 (2) FFB90208026A5 (4) 54504A5A5B556 (2) 604F484E5D587 (3) 7E32516207008 (2)
[13:38] <dfm> and if there are many nibbles bit bit errors, it is likely that one of them had so many actual errors, that it has been decoder to another codeword.
[13:38] <dfm> 5, 6, thats high.
[13:38] <dfm> in dist i put in a threshold, 4 i think.
[13:38] <SpacenearUS> New vehicle on the map: 03G8KHW_Tab2_chase - 12https://tracker.habhub.org/#!qm=All&q=G8KHW_Tab2_chase
[13:40] <dfm> so many bit-errors, but still no (F),
[13:41] <Darkside> 10db is where it reallt falls over
[13:41] <dfm> you can also try --ecc -r, maybe easier for statistics.
[13:42] <Darkside> 0C80253 [OK] 54504A5A5B556 [KO] 604F484E5D587 [KO]
[13:42] <dfm> OK means no errors (detected, could mean, there are so many errors that the codeword is valid again.)
[13:42] <Darkside> hmm
[13:42] <Darkside> why couldnt they have implemented a real CRC...
[13:42] <dfm> KO means, there have been errors, but correctable (if to the right codeword, unclear)
[13:43] <Darkside> hmm
[13:43] <Darkside> so for metrics, i could look for lines that have the three [OK]s in them?
[13:43] <dfm> NO means, one of the nibbles couldn't be corrected.
[13:44] <dfm> with hamming 7,4 this would not be possible, at least 8,4 gives a little more to decide.
[13:45] <dfm> If you assume, OK and KO is ok, then put them together. or you count only OK against the others, i.e. like no ecc. KO is the ecc-part.
[13:46] <Darkside> yeah
[13:46] <dfm> And maybe some blocks/frames are missing, when the header was missed.
[13:46] <Darkside> with ECC is easy, i already have that
[13:46] <Darkside> for no-ECC i guessi could just count the number of [OK]'s
[13:46] <dfm> with -r you get all the raw data blocks.
[13:46] <dfm> yes, i think. ok against KO+NO.
[13:47] <Darkside> i'd just do a count against the number OKs in the high-SNR file
[13:48] <dfm> There is still the small possibily, the the hamming code false detects some OK-frames, but this should be much. (there are 7-13 codewords in one block i think)
[13:48] <Darkside> ok, giving this a run...
[13:49] <dfm> The KO-blocks are a bit unreliable, when there are many bit-errors.
[13:49] <dfm> then the -R could give you a better impression. It only lists the 13-nibble blocks, where the gps-data is.
[13:52] <dfm> | grep "OK\|$" shows multiple OKs in one line.
[13:53] <dfm> colored, if color is turned on for grep
[13:54] <dfm> i mean, just fitering the line with ok is not enough, but python has probably an easy way to count this.
[13:55] <Darkside> grep can break out the intidivual instances of 'OK'
[13:55] <Darkside> grep -o '\[OK\]' | wc -l
[13:57] <dfm> and 1 second contains several blocks of course, but if you just calculate ratio, it doesn't matter.
[13:57] <Darkside> yeah
[13:57] <Darkside> just working on generating the numbers for the other modems
[13:57] <Darkside> and will produce a plot
[14:01] <dfm> and i think for rs92, the crc-option works a little different. i don't remember though, didn't use rs92 for some time. still think rs92 should be between rs41 and m10 with ecc.
[14:01] sumie-dh (~sumie-dh@91.146.121.5) joined #highaltitude.
[14:01] <Darkside> yeah theres probably somethign wrong there
[14:02] <SpacenearUS> New vehicle on the map: 03SP3KRE - 12https://tracker.habhub.org/#!qm=All&q=SP3KRE
[14:02] <Darkside> http://rfhead.net/sondes/plots/per_20190302_no_ecc.png
[14:02] <dfm> with rs92, maybe better also to work with: --ecc -r -v
[14:03] <dfm> raw output with error correction numbers at the end.
[14:03] <Darkside> ahh
[14:03] <Darkside> yeah
[14:03] <Darkside> for rs92 im just counting instances of the serial number
[14:03] <Darkside> which is probably not that good
[14:04] <Darkside> so in that case i'd be after errors: 0 ?
[14:05] <dfm> [NO] errors < 0 means to much for reed-solomon.
[14:05] <dfm> errors: 0 means 0 errors.
[14:05] <dfm> up to 12 errors can be corrected.
[14:05] <Darkside> ok
[14:06] <Darkside> so for a no-ecc test i'd just look for packets where there were no errors at all
[14:06] <Darkside> will give that a crack
[14:08] <dfm> so you put in 48kHz sample rate?
[14:08] <Darkside> yes
[14:08] <dfm> the decoders are not good at low rates, the don't interpolate.
[14:09] <Darkside> in all cases i resample back up to 48 khz
[14:10] <Darkside> ok now the RS92 plot is *much* worse
[14:10] <Darkside> which makes me think i have the filter bandwidth wrong
[14:10] <dfm> would be interested in rs41,dfm,rs92 with 48kHz -0.1 .. 0.1 and m10 -0.2 .. 0.2 bandwidth before fm, so resampling.
[14:10] <Darkside> yeah
[14:11] <Darkside> im just fiddlign with the sample rate parameter in rtl_fm
[14:12] <dfm> on sdr# i use 8kHz fm-filter bw for rs41,rs92, dfm, sometimes for rs41/92 down to 6.4kHz, m10 around 18-20kHz.
[14:13] <Darkside> what about highpass/lowpass filter on the output of the fm demod?
[14:14] <dfm> don't know how rtl_fm decimates, has only a few filter taps.
[14:14] <dfm> if signal is centered, don't use highpass.
[14:14] <Darkside> i'm using the -F9 option in rtl_fm
[14:15] <dfm> for narrow bw-filter, no lowpass need. only if it is wider. what kind of lowpass do you have in mind?
[14:15] <Darkside> hmm
[14:16] <Darkside> what i have in mind right now is that i should probably go to bed
[14:16] <dfm> if the lowpass is too low, the higher frequency pulses get smaller, thats not so good.
[14:16] <Darkside> since its almost 1AM
[14:17] <dfm> ok then
[14:18] <SpacenearUS> New vehicle on the map: 03KD9AIQ-11 - 12https://tracker.habhub.org/#!qm=All&q=KD9AIQ-11
[14:19] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) left irc:
[14:21] <SpacenearUS> New vehicle on the map: 03ND6W-6 - 12https://tracker.habhub.org/#!qm=All&q=ND6W-6
[14:22] <Darkside> yeah not sure abotu this RS92 decode chain
[14:22] <Darkside> definitely cant seem to make it any better
[14:22] <Darkside> i guess another point is its a plot of PER notBER
[14:22] <Darkside> so theres going to be offsets based on the number of bits per 'packet' (whatever a packet is defined to be)
[14:30] <Darkside> https://github.com/darksidelemm/radiosonde_auto_rx/blob/testing/auto_rx/test/notes/2019-03-02_performance_baseline.md
[14:30] <Darkside> right im going to bed :P
[14:58] <Ian_> Gnite :)
[15:05] chris_99 (uid26561@gateway/web/irccloud.com/x-iojwgixptcncobps) left irc:
[15:08] <SA6BSS-Mike> PE2BZ: yeap, they are realy taged along for quite some distance
[15:10] <PE2BZ> Kept hostage in the USA and released at the same moment ;-)
[15:11] <SA6BSS-Mike> :)
[15:12] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) joined #highaltitude.
[15:14] <dfm> To get a rough picture, i compare 10db rs41 vs rs92, same demodulation parameters, --ecc turned on:
[15:14] <dfm> rs41: 119/120
[15:15] <dfm> rs92: 72/120
[15:16] <dfm> A histogram of number of errors corrected.
[15:17] <dfm> rs92 can correct 12 bytes, rs41 2*12=24 bytes, the the shorter frames come with 0-padding, good for rs41, so rs92 has wider bits (manchester).
[15:18] <dfm> And rs41 had 21 frames with 13 errors or more (6,4,4,4,1,2,0,...,0) (13-24)
[15:20] <dfm> still some advantage to rs41, but thats only a rough comparison anyway. maybe the rs41 pulses are nicer or the clock is more accurate, or maybe the rs92 doesn't get that much attention any more.
[15:21] <dfm> maybe it would be fair also to look at rs41 aux-frames, which go almost all the distance, no zero-padding.
[15:22] <dfm> at lest to compare demodulation. on the other hand, for decoding the number of correct frames is what counts.
[15:23] tjq (uid339161@gateway/web/irccloud.com/x-rkgfjlfkddtuwmcs) left irc: Quit: Connection closed for inactivity
[15:23] <dfm> ? rs41-aux vs rs92, when comparing demodulation and ecc.
[15:25] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) left irc:
[15:28] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) joined #highaltitude.
[15:32] <dfm> darkside: so before i try to find it in your script, do you take frame-length into account, m10 has only 0.2s, rs41-standard 0.53s, the others transmit continuously.
[15:33] dfm (59cc9bbf@gateway/web/freenode/ip.89.204.155.191) left irc:
[16:17] Kodar (~Kodar@93-139-209-121.adsl.net.t-com.hr) left irc: Read error: Connection reset by peer
[16:21] #highaltitude: mode change '+o jonsowman' by ChanServ!ChanServ@services.
[16:21] #highaltitude: mode change '-o jonsowman' by ChanServ!ChanServ@services.
[16:27] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[16:27] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Client Quit
[16:44] Guest41131 (~anony@cpe-85-10-26-226.dynamic.amis.net) left irc: Read error: Connection reset by peer
[16:47] Sirius-BE (~BeB@8-117-44-5.dyn.ftth.fcom.ch) left irc: Remote host closed the connection
[16:49] Sirius-BE (~BeB@8-117-44-5.dyn.ftth.fcom.ch) joined #highaltitude.
[17:51] <SpacenearUS> New vehicle on the map: 03SP8GON-9 - 12https://tracker.habhub.org/#!qm=All&q=SP8GON-9
[18:12] zabow (~zab@host63-84-dynamic.250-95-r.retail.telecomitalia.it) left irc: Ping timeout: 245 seconds
[18:39] <SpacenearUS> New vehicle on the map: 03N4XWC-11 - 12https://tracker.habhub.org/#!qm=All&q=N4XWC-11
[18:42] <PE2BZ> PE2G pointed me to this url where you can see an anmiation of the weather from 2018 assembled from images from all common weathersatellites https://youtu.be/wVRbeGc_6zM
[19:31] tankcaptain (92e5ff15@gateway/web/freenode/ip.146.229.255.21) joined #highaltitude.
[19:33] tankcaptain (92e5ff15@gateway/web/freenode/ip.146.229.255.21) left irc: Client Quit
[19:38] <SpacenearUS> New position from 03KJ4TDM-11 after 037 days silence - 12https://tracker.habhub.org/#!qm=All&q=KJ4TDM-11
[19:42] sumie-dh (~sumie-dh@91.146.121.5) left irc: Ping timeout: 268 seconds
[19:48] sumie-dh (~sumie-dh@91.146.121.5) joined #highaltitude.
[20:00] xfce (~anony@cpe-85-10-26-226.dynamic.amis.net) joined #highaltitude.
[20:00] Nick change: xfce -> Guest60472
[20:32] <SpacenearUS> New position from 03N4XWC-1 after 037 days silence - 12https://tracker.habhub.org/#!qm=All&q=N4XWC-1
[20:56] BrainDamage_ (~BrainDama@unaffiliated/braindamage) joined #highaltitude.
[20:57] BrainDamage (~BrainDama@unaffiliated/braindamage) left irc: Ping timeout: 245 seconds
[20:57] Nick change: BrainDamage_ -> BrainDamage
[21:05] chris_99 (uid26561@gateway/web/irccloud.com/x-ymxfcwtiwpzmekvp) joined #highaltitude.
[21:27] Lahti2 (bc4354ca@gateway/web/freenode/ip.188.67.84.202) left irc: Quit: Page closed
[21:47] tjq (uid339161@gateway/web/irccloud.com/x-dghsptoemnbxaclp) joined #highaltitude.
[22:26] geheimnis` (~geheimnis@23.226.237.192) left irc: Remote host closed the connection
[22:30] geheimnis` (~geheimnis@23.226.237.192) joined #highaltitude.
[22:32] sumie-dh (~sumie-dh@91.146.121.5) left irc: Ping timeout: 245 seconds
[22:53] chris_99 (uid26561@gateway/web/irccloud.com/x-ymxfcwtiwpzmekvp) left irc:
[22:54] Nick change: en4rab_ -> en4rab
[23:27] OZ1SKY_Brian (~Brian@2-104-129-194-cable.dk.customer.tdc.net) left irc: Quit: Please pause the radiowaves !
[23:33] Action: Pit[m] uploaded an image: image.png (142KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/XhcHBVKnJPcvXiASHqMbPntT >
[23:33] <Pit[m]> Version: 20190227-beta
[23:34] <Pit[m]> looks like it could not decide 402.860 or 402.870
[23:35] <Darkside> aha, the first evidence of bad DFM drift...
[23:35] <Pit[m]> https://tracker.sondehub.org/?sondehub=1#!mt=osm&mz=11&qm=1_hour&f=RS_DFM09-18060079&q=RS_*;*chase
[23:35] <Darkside> that isue would have occured on any version btw
[23:36] <Pit[m]> other station does have decode. hmm, i have rtlsdr v3 stick with 0ppm
[23:36] <Pit[m]> but when the dfm drifts...
[23:36] <Darkside> yeah its a known issue
[23:36] <Darkside> and a difficult one to deal with in an automomous system
[23:39] sumie-dh (~sumie-dh@78.108.102.220) joined #highaltitude.
[23:47] stryx` (~stryx@unaffiliated/stryx/x-3871776) left irc: Remote host closed the connection
[23:49] stryx` (~stryx@unaffiliated/stryx/x-3871776) joined #highaltitude.
[23:55] <SpacenearUS> New vehicle on the map: 03VK5PET_chase - 12https://tracker.habhub.org/#!qm=All&q=VK5PET_chase
[00:00] --- Sun Mar 3 2019