highaltitude.log.20190316

[00:30] Hoogvlieger (~Hoogvlieg@541A8CEB.cm-5-3c.dynamic.ziggo.nl) joined #highaltitude.
[01:47] <TimMc_> ST-LINK V2 arrived! Flashed RS41HUP from Darkside.
[02:02] <Darkside> cool
[03:14] <TimMc_> st-flash running into issues (not sure what memory address to write to >.<). Now trying blackmagic probe
[03:30] <Darkside> i did have issues under linux
[03:30] <Darkside> ended up using the stilink utility on windos a lot
[03:55] tweetBot1 (~nodebot@philcrump.co.uk) left irc: Remote host closed the connection
[03:55] tweetBot (~nodebot@philcrump.co.uk) joined #highaltitude.
[04:04] jayvee (~quassel@2402:1f00:8100:400::d60) left irc: Quit: No Ping reply in 180 seconds.
[04:07] jayvee (~quassel@2402:1f00:8100:400::d60) joined #highaltitude.
[04:15] tjq (uid339161@gateway/web/irccloud.com/x-rqeeemnshewsfozd) left irc: Quit: Connection closed for inactivity
[04:16] <SpacenearUS> New position from 03U3B-25 after 0313 hours silence - 12https://tracker.habhub.org/#!qm=All&q=U3B-25
[05:41] matb (~matb@104.206.241.26) left irc: Quit: Ping timeout (120 seconds)
[05:42] matb (~matb@104.206.241.26) joined #highaltitude.
[05:59] Kodar (~Kodar@93-139-174-43.adsl.net.t-com.hr) joined #highaltitude.
[06:30] Lahti (~Lahti@82-203-175-254.bb.dnainternet.fi) joined #highaltitude.
[06:38] xfce (~anony@cpe-85-10-26-226.dynamic.amis.net) joined #highaltitude.
[06:38] Nick change: xfce -> Guest56697
[07:30] Viproz__ (~Viproz@unaffiliated/viproz) joined #highaltitude.
[07:33] Viproz_ (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 245 seconds
[07:42] <Darkside> Viproz__: yo
[07:43] Viproz_ (~Viproz@unaffiliated/viproz) joined #highaltitude.
[07:46] Viproz__ (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 246 seconds
[07:55] SA6BSS-Mike (~SA6BSS-Mi@h-155-4-222-217.NA.cust.bahnhof.se) joined #highaltitude.
[08:03] OZ7EMA (~emanuel_@151.36.32.10) joined #highaltitude.
[08:05] YO9GJX (~YO9GJX@109.100.112.75) left irc: Remote host closed the connection
[08:06] YO9GJX (~YO9GJX@109.100.112.75) joined #highaltitude.
[08:10] Guest56697 (~anony@cpe-85-10-26-226.dynamic.amis.net) left irc: Ping timeout: 246 seconds
[08:10] Hoogvlieger (~Hoogvlieg@541A8CEB.cm-5-3c.dynamic.ziggo.nl) left irc: Quit: Leaving
[08:26] OZ7EMA (~emanuel_@151.36.32.10) left irc: Quit: My MacBook has gone to sleep. ZZZzzz&
[08:45] vipstaaki (~oh2aue@dsl-lhtbng12-54fa75-194.dhcp.inet.fi) left irc: Ping timeout: 252 seconds
[08:45] YO9GJX (~YO9GJX@109.100.112.75) left irc: Remote host closed the connection
[08:47] YO9GJX (~YO9GJX@109.100.112.75) joined #highaltitude.
[08:47] YO9GJX (~YO9GJX@109.100.112.75) left irc: Remote host closed the connection
[08:49] <TimMc_> "Error erasing flash with vFlashErase packet" when loading RS41HUP.elf in Linux via gdb with a BM21 >.<
[08:52] <Darkside> yes i had similar issues too
[08:52] <Darkside> i had to do the first flash under windows
[09:05] g0hww (~g0hww@46.18.105.34) left irc: Remote host closed the connection
[09:17] <SpacenearUS> New vehicle on the map: 03SP1ZZW - 12https://tracker.habhub.org/#!qm=All&q=SP1ZZW
[09:18] <TimMc_> Darkside: Ah. I managed to figure out the Option Bytes part in the STM32 Utility and unchecked all the protected memory locations :D
[09:30] <TimMc_> Constant stream of stuff produced on 434.650
[09:30] <Darkside> thats the idea
[09:35] <TimMc_> Now, to decode :P
[09:36] <TimMc_> I was thinking of wiring RS41s up to some fox traps in remote areas and have a receiver setup on a farm to detect when an animal sets off the trap.
[09:38] <TimMc_> Soft leghold trap with chain pegged to the ground, burried. And some cages that have a door that slides shut.
[09:39] dfm (59cc9b29@gateway/web/freenode/ip.89.204.155.41) joined #highaltitude.
[09:40] <Darkside> hi dfm
[09:40] <dfm> morning
[09:40] <Darkside> dfm: any thoughte in the imet serial number issue?
[09:40] <Darkside> as far as i can tell theres no unique ID sent in the imet-4 telemetry
[09:41] <dfm> don't no much about the imet, i think this open data protocol doesn't offer much.
[09:41] <dfm> (just commented there)
[09:41] <Darkside> yeah
[09:41] <Darkside> with the DFM sondes we intentially dont upload until we get an ID
[09:41] <Darkside> to avoid issues
[09:42] <Darkside> i think with the iMets theres going to be no option other than to have the user supply a monitoring location
[09:42] <Darkside> or an area name
[09:42] <Darkside> its goign to be a massive painits going to be a massive pain
[09:42] <Darkside> urgh
[09:44] <dfm> don't have much experiences with imet4, but ...
[09:46] <Darkside> im using your imet1rs_dft decoder, and its working fine
[09:47] <dfm> searching for a name wait
[09:47] <Darkside> but yeah, unless theres something hidden 'outside' the packet, i don tthink theres any ID available
[09:47] <dfm> ok, anyway, if (most of the) imets4 don't transmit it, its still a problem, even if there would be other possible data packets...
[09:48] <Darkside> yup
[09:48] <Darkside> i have a stock imet4 out of th ebox
[09:48] <Darkside> out of the box*
[09:48] <dfm> Here
[09:48] <dfm> https://github.com/bobasaurus
[09:48] <Darkside> and yeah, doesnt look to have any id data
[09:49] <dfm> he knows about imet1rs, probably you can ask him
[09:49] <Darkside> ok
[09:50] <dfm> I mean, the imet4 and imet1rs i received transmitted only pcks 0x01 and 0x04, it is not much data.
[09:50] <Darkside> yeah thats all i have too
[09:50] <Darkside> at least the packet format is open!
[09:50] tjq (uid339161@gateway/web/irccloud.com/x-svkqzvnkiiugppvb) joined #highaltitude.
[09:51] <dfm> so maybe it is possible to select more/enhanced data transmittion, but anyway, the imets that don't do this, still are anonymous.
[09:52] <dfm> There is the frequency/date, so how likely is it that 2 imet4 fly on the same frequency on one day?
[09:52] <Darkside> not sure tbh
[09:52] <dfm> If it would be graw or vaisala, ok, that would be a problem, but imet.
[09:53] <Darkside> but yeah, i was thinking perhaps we make up an ID based on a user-defined parameter and perhaps some date-based field
[09:53] <dfm> If you have a central server, you could enumerate or ask for the next imet-id.
[09:53] <Darkside> ill have to have a think about that
[09:53] <Darkside> i really wanted to avoid that kind of solution
[09:54] <dfm> i have to admit i don't know how auto_rx works, didn't try it yet...
[09:54] <Darkside> from a local observation stabdpoint it doesnt matter so much
[09:55] <Darkside> but to upload positionfor for multiple stations to upload positions to the network, there needs to be a common ID used
[09:56] <dfm> So the counter, maybe not so important for burst as the new default value is something like 510min, but some stations use this kill timer. When it is 200min, it ca really be just after landing...
[09:57] <Darkside> yeah, so i'm just using the countdown field
[09:57] <Darkside> and i only use it just after it starts counting down
[09:58] <dfm> I wanted to recover one once, and when i came there, opened the laptop, maybe 10 frames and over... ;) lucky i didn't try to set up maps or something...
[09:58] <Darkside> hehe
[09:58] <Darkside> well thats where having something like auto_rx running on a pi in the car helps :-)
[09:58] <Darkside> auto scans, decodes, logs, uploads, etc :-)
[09:58] <dfm> so i donÄt know if you can set both, burst and time kill
[09:58] <Darkside> yeah not sure
[09:59] <Darkside> i think its becoming a bit rarer nowdays anyway
[09:59] <Darkside> pretty much all launch sides just use the default maximum timeout (8.5 hrs)
[09:59] <Darkside> still nice to know how long you have until it turns off
[09:59] <dfm> and launch i don't know if/how you select full power mode.
[10:00] <dfm> but if you live near a launch station, maybe you observed it, after some 600m above ground, how it switches to full power, same in australia?
[10:00] <Darkside> not sure actually
[10:00] <Darkside> havent paid that much attention to the RX power
[10:00] <Darkside> i expect it will be similar though
[10:01] <Darkside> i am setting up a station soon that will be able to see the signals from the radiosondes before they launch
[10:01] <Darkside> so i might be able to get some info using that receiver
[10:01] <dfm> and at this point you see that in 0x32 there is more data changed.
[10:01] <Darkside> ok interesting
[10:01] <Darkside> i'd like to know where the author of RS41Tracker got his information
[10:01] <Darkside> because he's decoding a whole lot of fields
[10:02] <Darkside> some of them which must have been very difficult to decipher
[10:02] <dfm> don't have many examples, but the 3rd byte is 07, the first 2 (at this position) could be approximately the altitude above start.
[10:03] <dfm> so i guess it is rather altitude than time.
[10:03] <dfm> well, some informations you find on the internet, github, most of it.
[10:04] <Darkside> i tried to get some meaning out of the dxlAPRS code... but man, that codebase is hard to read
[10:04] <dfm> ptu calculations from raw to ptu, ok, but the rest, all the gps data is in the decoder here.
[10:05] <dfm> no, all the constants... ;)
[10:05] <dfm> so what are you looking for?
[10:05] <Darkside> oh i was looking for what they were using for the burst timer
[10:06] <Darkside> but i ended up figuring it out just by looking at the packets over time
[10:06] <Darkside> was easier :-)
[10:06] <Darkside> pretty obvious, just look for the decrementing butes
[10:06] <Darkside> bytes*
[10:07] <dfm> did they have this counter? don't know, don't look there much... if you don't know where it comes from, what do you know then?
[10:07] <dfm> at least i try to explain, although most in german back then.
[10:07] <Darkside> theres a bit of commented out code there which talks about the counter
[10:07] <Darkside> but anyway, it doesnt matter
[10:08] <Darkside> we have the numbers we need
[10:08] <Darkside> the only extra thing that woudl be nice is humidity, but i dont think they calculate that either
[10:08] <dfm> ok, that is something for the future.
[10:09] <dfm> the raw data is obvious, and for rs41 the calibration is in the data, though for humidity it is probably some more coefficients.
[10:09] <Darkside> yeah
[10:10] <dfm> it is an interesting subject, so only copying is boring.
[10:11] <Darkside> yup
[10:11] <Darkside> thoughi suspect something like humidity is going to be pretty complicated to figure out without some other information
[10:11] <Darkside> anyway, its not urgent
[10:11] <dfm> but comparing to published ptu-data, since it is not published for every frame, takes some time.
[10:11] <Darkside> yeah
[10:11] <dfm> but i put that aside, first a little more on demodulation.
[10:11] <Darkside> yep no probs
[10:12] <Darkside> so i've got an experimental branch now where i use fsk_demod for RS41/RS92/DFM and M10
[10:12] <Darkside> only tested it 'in the wild' with RS41s
[10:12] <dfm> the rs41mod version can read binary data.
[10:12] <Darkside> but yeah, will switch to whatever works best
[10:13] <Darkside> RS41s FM demod works fine
[10:13] <Darkside> DFMs are where the issue is i think, because of the drift
[10:13] <dfm> so there is a little problem when losing signal quality infomation, header detection could be false.
[10:14] <dfm> i have dfm and m10 also ready, have to clean up, but there you could directly feed binary data as well.
[10:14] <Darkside> ok
[10:14] <dfm> and since it is more modulare, yuo could even forget about demod_mod.
[10:14] <Darkside> so just feed bits into the decoder section you mean
[10:14] <Darkside> no CPU time spent on the demodulation part
[10:14] <Darkside> that would be good
[10:15] <dfm> however, the dfm is very sensible when detecting the header, if you don't have snr-info.
[10:15] <Darkside> ok
[10:16] <Darkside> ok, time to finish up adding i the burst timer stuff.. i want to get that released soon, as its really useful
[10:16] <dfm> the header is short, and if you allow some bit_errors, it could be misdetected as the inverse header somewhere else in the frame.
[10:16] <Darkside> going to go for a sonde chase tomorrow and intentionally leave the sonde on when i recover it, to watch the counter count down
[10:16] <dfm> but how about the new repo RS_autorx or something like it?
[10:17] <Darkside> just keeping it in a directory is OK
[10:17] <Darkside> i can use a git submodule to pull that particular directory in
[10:17] <dfm> then you don't need all the other files, my RS-repo is more like a notebook for me, the ne "sub-"repo would be cleaner.
[10:18] <dfm> ah, ok, maybe thats enough.
[10:18] <Darkside> or i can just pull in files as you do updates, kind of like im doing now
[10:18] <dfm> so i wanted to test iq-demodulation a little more.
[10:18] <Darkside> IQ demodulation is nice as the decode chain is so simple
[10:18] <dfm> the problem with dfm seems to be, the fm-transmittion is not really constant amplitude
[10:19] <Darkside> yeah i've noted that
[10:19] <dfm> and then this spike appear, when amplitude goes close to zero.
[10:19] <Darkside> ok not sure about that
[10:19] <dfm> iq-decoding dfm is much better, at least if you don't filter the fm-signal.
[10:20] <dfm> but needs other parameters.
[10:20] <dfm> and having different sets of parameters for rs41, dfm, m10, maybe even dfm06/dfm09/dfm17, other the modulation index....
[10:21] <Darkside> well we can already detect the difference between RS41, RS92, DFM and M10
[10:21] <Darkside> so for those have a set of parameters for each, for DFM maybe a starting set, and then once the exact type is determined refine parameters
[10:21] <dfm> because if you can rely on constant amplitude, you could average/filter a bit, helps rs41, but dfm does it's on thing. (or was it the recording?)
[10:22] <Darkside> were you using my recording?
[10:22] <Darkside> i tried my best to keep the levels flat, but there might be some variation
[10:22] <dfm> no, i mean using some custom filtering-
[10:23] <dfm> I think some string iq-recordings i have showed the same, the amplitude variation of the dfms is much higher.
[10:24] <dfm> don't know if it is really necessary or even the another reason for wider bandwidth, it is not only the high modulation index.
[10:25] <dfm> yes, your recording, the old (have you normalized?), but I looked through some other dfm-signals I recorded, looks similar.
[10:25] <Darkside> i haven uploaded normalised camles, no
[10:25] <Darkside> probably shoudl do that
[10:26] <dfm> i normalized it, looks clean, but also you see immediately, that the iq-amplitude is not nearly constant.
[10:27] <dfm> QPSK-decoders rely on constant amplitude much more I think...
[10:29] <dfm> Anyway, this complex gaussian noise, a nice example, when you add it to real and imaginary, how its in added to the complex signal.
[10:29] <dfm> didn't put it right
[10:30] <Darkside> when I generate my noisy samples?
[10:31] <dfm> i mean, if you would take uniform randomness, you would get squares/1-norms, so in c, you first have to produce normal distribution, and this is a good example.
[10:31] <dfm> "you" i mean "one", in general.
[10:36] <dfm> What I tried to say: In C if you want to simulate SNR, it is some more work from uniform rand to gaussian noise. in python it is only randn, and the little 'n' is overlooked easily.
[10:36] <dfm> what difference it makes.
[10:37] <Darkside> oh
[10:37] <Darkside> so yes, randn is gaussian normal distribution
[10:37] <Darkside> mean 0, variance 1
[10:37] <Darkside> which is then easy to change to whartever variance you want
[10:37] <dfm> probability is mostly counterintuitive anyway
[10:39] <dfm> yes, and you add it to real and imag part and get circular symmetric complex normal distribution
[10:40] <Darkside> yeah, i add seaprate random distributions to real and imag
[10:41] <dfm> yes, everything ok.
[10:41] <Darkside> https://github.com/projecthorus/radiosonde_auto_rx/blob/master/auto_rx/test/generate_lowsnr.py#L83
[10:43] <dfm> only if you imagine random numbers as uniform distributed in a certain interval like some simple rand-function would give, and add it to real and imag, it would be a square. My point is, thinking about normal distribution and how it behaves in e.g. 2 dimensions, is not so intuitive, as many things in probability. at least if you don't do it every day.
[10:43] <Darkside> yes
[10:44] <Darkside> its 'complex' ;-)
[10:44] <dfm> But for motivation, signal processing and noise is a good example i guess.
[10:49] <dfm> So if you want to try rs41mod with binary data, it is just --bin <file.bin> (if i remember right), takes bit/byte or 0x30+bit / byte.
[10:50] <Darkside> ok will give it a go at some point
[10:50] <dfm> And I moved polarity further out, auto-detection should work.
[10:52] <dfm> with 8byte header, false detection in between frames should be minimal, though your demodulator sents bits al the time. so some soft/bitscore-value could be useful someday.
[10:52] <Darkside> well it can output floating point softbits now
[10:52] <Darkside> i think they are between 0 and 1
[10:52] <Darkside> would have to check with the author
[10:53] <dfm> also maybe for ecc, if normal error correction false, some erasure-test could be done, at least if one of the codewords was correct.
[10:55] <SpacenearUS> New vehicle on the map: 03DF0MN-12 - 12https://tracker.habhub.org/#!qm=All&q=DF0MN-12
[11:03] sumie-dh (~sumie-dh@78.108.102.220) left irc: Ping timeout: 246 seconds
[11:04] <dfm> looks like a kill-timer rs41 is on air again, 402.7, Kuemmersbruck, and Idar-Oberstein (also 402.7) often do this. But changed from 3:20h to 5h.
[11:09] chris_99 (uid26561@gateway/web/irccloud.com/x-nulgifubuhigglbj) joined #highaltitude.
[11:12] dfm (59cc9b29@gateway/web/freenode/ip.89.204.155.41) left irc:
[11:12] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) joined #highaltitude.
[11:24] dfm (59cc9b29@gateway/web/freenode/ip.89.204.155.41) joined #highaltitude.
[11:31] <dfm> Darkside: If you want to generate a new DFM snr sample, maybe you could try using a little less power/gain. After all it looks like there is clipping somewhere, and it seems unlikely that the transmitter was doing that with I and Q.
[11:33] <Darkside> yeah probably a good idea
[11:33] <Darkside> i have a SMA socket soldered onto the DFM09 i have
[11:33] <Darkside> can put attenuators in line and get the signal to a good level
[11:35] <dfm> When I record with sdrsharp and use the raw-demodulation with which I can iq-demod live, I get clipping easily, because you have either no-gain or at least 26db ("audio") gain, and with a strong signal it is at the edge, he clips the audio very low below 1.
[11:36] <dfm> although when recording iq directly there is no problem, there is no addiition "audio" gain, but I don't know if there is a very strong signal, if he would let through the i and q between -1 and 1.
[11:37] <dfm> and the rtl-sdr gain=0.
[11:38] <dfm> the dfm09 recording was stronger than the others?
[11:39] <Darkside> not particularly
[11:39] <dfm> when the signal level is somewhere around 0.1 (float), the float resolution should be still enough for only minor quantization errors.
[11:40] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) left irc: Ping timeout: 245 seconds
[11:43] <dfm> sma socket? do you mean you take the signal directly from the radiosonde, not over antenna?
[11:44] Nick change: Viproz_ -> Viproz
[11:46] <Darkside> dfm: i may try that this time, to get a more consistent signal level
[11:46] <Darkside> lots of attenuators
[11:48] <dfm> over antenna? I think at near distance it is absolutely ok to receiver the antenna signal, it is rather to strong, but should be good enough, and in real world it is transmitted in air anyway.
[11:48] <Darkside> its more that with receiver and transmitter in close proximity, me moving around causes signal level changes
[11:49] <dfm> doing radar?
[11:49] xfce (~anony@cpe-85-10-26-226.dynamic.amis.net) joined #highaltitude.
[11:50] Nick change: xfce -> Guest41089
[12:02] YO9GJX (~YO9GJX@109.100.112.75) joined #highaltitude.
[12:05] dfm (59cc9b29@gateway/web/freenode/ip.89.204.155.41) left irc:
[12:20] tjq (uid339161@gateway/web/irccloud.com/x-svkqzvnkiiugppvb) left irc: Quit: Connection closed for inactivity
[12:24] <SpacenearUS> New vehicle on the map: 03pb0ahx_chase - 12https://tracker.habhub.org/#!qm=All&q=pb0ahx_chase
[12:27] sumie-dh (~sumie-dh@91.146.121.5) joined #highaltitude.
[12:35] sumie-dh (~sumie-dh@91.146.121.5) left irc: Ping timeout: 245 seconds
[12:44] <Pit[m]> how to split a antenna signal in 3-ways with minimal loss?
[12:45] <Pit[m]> how bad are these https://www.ebay.de/itm/3-Way-RF-Power-Splitter-Divider-Combiner-1-to-3-SMA-F-380-2500MHz-Wifi-Repeater/322793010961
[12:45] <Pit[m]> Insertion loss: d2.5db 🤔 i bet its more
[12:47] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) joined #highaltitude.
[12:48] Viproz (~Viproz@unaffiliated/viproz) left irc: Ping timeout: 246 seconds
[12:48] <Darkside> Pit[m]: well its going to be at least 4.77 db...
[12:49] <Darkside> since thats 10log(3)
[12:49] <Pit[m]> i should build one with a lna in each split
[12:50] <Darkside> a lna before the splitter is fine
[12:50] <Darkside> realistically if you have a LNA before the splitter you probably wont impact your system noise figure anyway
[12:56] furetsuya (~oh2aue@dsl-lhtbng12-54fa75-194.dhcp.inet.fi) joined #highaltitude.
[13:50] <SpacenearUS> New vehicle on the map: 03KD0HIP-7 - 12https://tracker.habhub.org/#!qm=All&q=KD0HIP-7
[13:59] Steffanx (~steffanx@unaffiliated/steffanx) left irc: Ping timeout: 246 seconds
[14:13] YO3ICT (547554ec@gateway/web/freenode/ip.84.117.84.236) joined #highaltitude.
[14:25] <SpacenearUS> New vehicle on the map: 03W5LCY-7 - 12https://tracker.habhub.org/#!qm=All&q=W5LCY-7
[14:30] Viproz (~Viproz@unaffiliated/viproz) joined #highaltitude.
[14:33] es5nhc (~es5nhc@96-247-29-85.dyn.estpak.ee) joined #highaltitude.
[14:47] YO9GJX (~YO9GJX@109.100.112.75) left irc: Remote host closed the connection
[14:56] pd3jag (55912c76@gateway/web/freenode/ip.85.145.44.118) joined #highaltitude.
[14:57] pd3jag (55912c76@gateway/web/freenode/ip.85.145.44.118) left irc: Client Quit
[14:57] Medad (92a9b60e@gateway/web/freenode/ip.146.169.182.14) joined #highaltitude.
[15:03] browen_ (5ee21c41@gateway/web/freenode/ip.94.226.28.65) joined #highaltitude.
[15:12] sumie-dh (~sumie-dh@91.146.121.5) joined #highaltitude.
[15:21] Viproz (~Viproz@unaffiliated/viproz) left irc: Read error: Connection reset by peer
[15:29] <SpacenearUS> New position from 03U3B-25 after 0311 hours silence - 12https://tracker.habhub.org/#!qm=All&q=U3B-25
[15:32] Zathras[m] (zathrasmat@gateway/shell/matrix.org/x-waajifdvitlaccgh) left irc: Remote host closed the connection
[15:32] purewhite[m] (purewhitem@gateway/shell/matrix.org/x-qqhypaatuwoolkig) left irc: Remote host closed the connection
[15:32] Pit[m] (pit711matr@gateway/shell/matrix.org/x-zvobvajjpmhdoixt) left irc: Remote host closed the connection
[15:32] snh (snhmatrixo@gateway/shell/matrix.org/x-vslqxlccflsbumtg) left irc: Remote host closed the connection
[15:34] browen_ (5ee21c41@gateway/web/freenode/ip.94.226.28.65) left irc: Quit: Page closed
[15:36] fl_0 (unknown@unaffiliated/fl-0/x-7355575) left irc: Ping timeout: 255 seconds
[15:37] fl_0 (unknown@unaffiliated/fl-0/x-7355575) joined #highaltitude.
[15:39] es5nhc (~es5nhc@96-247-29-85.dyn.estpak.ee) left irc: Ping timeout: 268 seconds
[15:39] Medad (92a9b60e@gateway/web/freenode/ip.146.169.182.14) left irc: Ping timeout: 256 seconds
[15:43] Zathras[m] (zathrasmat@gateway/shell/matrix.org/x-cmmnpimjvkwwrkhp) joined #highaltitude.
[15:51] <SpacenearUS> New position from 03KN4KFG-11 after 0318 hours silence - 12https://tracker.habhub.org/#!qm=All&q=KN4KFG-11
[15:52] purewhite[m] (purewhitem@gateway/shell/matrix.org/x-ihaapqoblwkntpnh) joined #highaltitude.
[15:53] Pit[m] (pit711matr@gateway/shell/matrix.org/x-casxmxivlcxvrnwr) joined #highaltitude.
[15:53] snh (snhmatrixo@gateway/shell/matrix.org/x-asepkumootrcuhli) joined #highaltitude.
[16:13] <SpacenearUS> New vehicle on the map: 03ICT1 - 12https://tracker.habhub.org/#!qm=All&q=ICT1
[16:13] YO9GJX (~YO9GJX@109.100.112.75) joined #highaltitude.
[16:23] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[16:25] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Client Quit
[16:33] The20YearIRCloud (uid38883@gateway/web/irccloud.com/x-zglbkjwdhfzelihp) left irc: Quit: Connection closed for inactivity
[17:04] Medad (92a9b890@gateway/web/freenode/ip.146.169.184.144) joined #highaltitude.
[17:14] Medad (92a9b890@gateway/web/freenode/ip.146.169.184.144) left irc: Quit: Page closed
[17:20] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[17:20] cgosling (1827521e@gateway/web/freenode/ip.24.39.82.30) joined #highaltitude.
[17:20] cgosling (1827521e@gateway/web/freenode/ip.24.39.82.30) left #highaltitude.
[17:22] <F5MVO> IS THE GEODESIC ALTITUDE TAKEN INTO ACCOUNT SOMEWHAT in radiosonde autorx ?
[17:22] <F5MVO> hello
[17:40] cgosling (1827521e@gateway/web/freenode/ip.24.39.82.30) joined #highaltitude.
[17:40] cgosling (1827521e@gateway/web/freenode/ip.24.39.82.30) left #highaltitude.
[17:47] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Quit: Page closed
[17:50] ribbotson (~ribbotson@host109-147-67-107.range109-147.btcentralplus.com) joined #highaltitude.
[17:52] <Pit[m]> i dont think so, dxlAPRS uses it https://github.com/oe5hpm/dxlAPRS/search?q=geoid&type=Commits
[17:53] ribbotson (~ribbotson@host109-147-67-107.range109-147.btcentralplus.com) left irc: Client Quit
[17:54] <Pit[m]> looks like its enabled https://github.com/projecthorus/radiosonde_auto_rx/search?q=geoid&unscoped_q=geoid
[18:07] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[18:18] sumie-dh (~sumie-dh@91.146.121.5) left irc: Ping timeout: 272 seconds
[18:41] chris_99 (uid26561@gateway/web/irccloud.com/x-nulgifubuhigglbj) left irc:
[19:07] Steffanx (~steffanx@unaffiliated/steffanx) joined #highaltitude.
[19:07] Steffann (~steffanx@unaffiliated/steffanx) joined #highaltitude.
[19:10] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Quit: Page closed
[19:18] YO3ICT (547554ec@gateway/web/freenode/ip.84.117.84.236) left irc: Quit: Page closed
[19:49] sumie-dh (~sumie-dh@91.146.121.5) joined #highaltitude.
[20:09] <SpacenearUS> New position from 03KC2VMF after 038 days silence - 12https://tracker.habhub.org/#!qm=All&q=KC2VMF
[20:21] cgosling (8e69f3d3@gateway/web/freenode/ip.142.105.243.211) joined #highaltitude.
[20:21] cgosling (8e69f3d3@gateway/web/freenode/ip.142.105.243.211) left #highaltitude.
[20:57] sumie-dh (~sumie-dh@91.146.121.5) left irc: Ping timeout: 272 seconds
[20:59] Steffanx (~steffanx@unaffiliated/steffanx) left irc: Quit: Meh
[20:59] Nick change: Steffann -> Steffanx
[21:23] michal_f (~mfratczak@91-145-163-242.internetia.net.pl) left irc: Ping timeout: 250 seconds
[21:42] sumie-dh (~sumie-dh@78.108.102.220) joined #highaltitude.
[21:45] Lahti (~Lahti@82-203-175-254.bb.dnainternet.fi) left irc: Quit: Lähdössä
[22:28] tjq (uid339161@gateway/web/irccloud.com/x-xgiwyebqkiicfysp) joined #highaltitude.
[22:29] The20YearIRCloud (uid38883@gateway/web/irccloud.com/x-hpoephlxhxngauxc) joined #highaltitude.
[22:31] tjq (uid339161@gateway/web/irccloud.com/x-xgiwyebqkiicfysp) left irc: Client Quit
[22:47] sumie-dh (~sumie-dh@78.108.102.220) left irc: Ping timeout: 246 seconds
[23:07] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[23:08] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Client Quit
[23:11] Guest41089 (~anony@cpe-85-10-26-226.dynamic.amis.net) left irc: Read error: Connection reset by peer
[23:11] LazyLeopard (~irc-clien@82.152.120.241) joined #highaltitude.
[23:13] LazyLeopard (~irc-clien@82.152.120.241) left irc: Client Quit
[23:22] Kodar (~Kodar@93-139-174-43.adsl.net.t-com.hr) left irc: Read error: Connection reset by peer
[00:00] --- Sun Mar 17 2019