iMS-100 data availible about rs HOT 67 CLOSED

If you record FM-audio, don't use any filters,
48kHz sampling rate would be fine, 8bit/sample is ok.

A baseband recording would be interesting, since I have never seen how the signal looks like in frequency space. 30-60 sec at 1 MHz would be nice; maybe I could do a small video example for signal identification.
(The audio samples I have are ims-100 and rs-11g I believe, but I'm not absolutely sure which one is which.)

from rs.

Sorry I thought I came back to you before, yes I recorded the data as you described above. Quite a lot of it in fact, but have been busy with other projects of late.
I also grabbed the released data for the flight from BMKG.

Can you suggest how to pass it across? I think I could put it up on google drive, files look a bit big for email.

from rs.

Yes, something like dropbox or google drive would be fine.

from rs.

I had a look and see I replied about having the data on 5th June to what was probably a no return github email.

Can you mail me on harrycam3 so I can send you the link for the data.
I use the normal gmail dot com after that, and in the meantime I will see about uploading the data somewhere for you.

from rs.

Some iMS-100 samples are here: https://rfhead.net/sondes/meisei/

from rs.

The audio sample decodes OK with: cat SDRSharp_20190821_004808Z_404404266Hz_AF.wav | ./meisei_ims -2

from rs.

Okay, you got some samples. Was going to point to this thread ...
Don't have enough data/information, but it could be that the sonde-type or frame-data-version is in the data, for the ims100 samples that I know it is always the same byte at this position.
And also there is a 14-16 byte block numbered 0..3 that looks like config data, though sometimes the data in there seems shifted (?), don't know if it is really constant, but maybe the serial number is in there. If someone finds a ims100 that was decoded, it would help. Serial number or ID would be good for sondehub.

FB6230 .... .... 0300: PRNs ?

from rs.

After the frame-counter, there is constant data repeating every 64 frame-counts, all the numbers look like not-to-small not-to-big float32. Some are integers, one repeats every 16 frame-counts (smallest period).
Probably config/calib-data. The document GRUAN-TD-5_MeiseiRadiosondes_v1_20180221.pdf describes the JMA Format that has some similiarity to the ims100-data (maybe it is the exchange data format?), also including serial number at a similar position in the subframe.

E.g. 2019-06-12:

049DCE 2000 8F31 F386 4AD5 0000 : 4AD5F386 -> 7010755
049DCE 2001 0000 0000 0000 0000
049DCE 2002 800D 8D3A 4AE8 0000 : 4AE88D3A -> 7620253
049DCE 2003 3BE2 0000 4353 0000 : 43530000 -> 211
049DCE 2004 8F31 3054 4ADF 0000 : 4ADF3054 -> 7313450
049DCE 2005 0000 0000 0000 0000
049DCE 2006 8013 3000 470E 0000 : 470E3000 -> 36400
049DCE 2007 3BDA 0000 0000 0000
049DCE 2008 8F31 0000 0000 0000
049DCE 2009 0000 0000 0000 0000
049DCE 200A 800C 0000 0000 0000
049DCE 200B 3BC7 0000 0000 0000
049DCE 200C 8F30 0000 0000 0000
049DCE 200D 0000 0000 0000 0000
049DCE 200E 800F 05E4 4AD9 0000 : 4AD905E4 -> 7111410
049DCE 200F 3BA2 0000 4220 0000 : 42200000 -> 40
049DCE 2010 8F31 F386 4AD5 0000 : 4AD5F386 -> 7010755
...

There are also numbers with more decimal places, however the one that repeats most often (mod 16) is F386 4AD5 (7010755 as float).
Could this be the serial number of the radiosonde?
In the recording above from 2019-08-21:

049DCE 3200 8E31 F39E 4AD5 0000 : 4AD5F39E -> 7010767
..
049DCE 3210 8E31 F39E 4AD5 0000
..

In this video
https://www.youtube.com/watch?v=uP1TiPSxWZM
there are 64 parameters, and the Serial Number pops up at FCnt 64: 6015018 (unfortunately audio does not decode).

from rs.

2019-08-21, 404.4 MHz (100kHz steps):
cal_20190821_404400kHz_64.txt.gz

Frequency might be 15/64:
400000+fq*100 kHz
15 # 0000 4230 : 0x42300000 = 44.000 fq = 404400 kHz

Also matches Lindenberg recordings:
2019-04-02, 402.5MHz:
15 # 0000 41C8 : 0x41c80000 = 25.000 fq = 402500 kHz
2019-04-02, 403.5MHz:
15 # 0000 420C : 0x420c0000 = 35.000 fq = 403500 kHz
2014-10-09, 403.2MHz:
15 # 0000 4200 : 0x42000000 = 32.000 fq = 403200 kHz

from rs.

I think you mentioned that dft_detect now detects these sondes? If you can get a decoder going with JSON output (even if it doesn't have an ID), I can get a testing branch of auto_rx going so that vk3-hca can at least try and track a few. Recovery might be difficult given where he is is essentially an archipelago, but you never know...

from rs.

Yes Frequency is in the data stream for that JMT data base format we are discussing. 404.4 is the normal DPS freq for all for the recordings I have made, I think one week it was 404.5 but Surabaya is normally 403.6 you might be able to look at the Surabaya sample from a few weeks ago to verify that. Today s Surabaya was on down 404.4 but the modified dft_detect I cut into auto_rx did not pick it up. Quite possibly an antenna related issue. See what happens with the Yagi in the morning if I get to tune it up and put it up high tonight.

Still no update onto days recovered sonde, hoping its still alive on external power with no burst timer, just have to wait.

from rs.

If it does detect it, auto_rx won't know how to deal with the detection until I add it :-)

from rs.

I cut in the latest version dft_detect and decoder since we have got the dft_detect and IMS100 decoder going and verified it.
Cut being quite brutal, much better Mark you do it, as I am a machine code guy who was taught 6800 in hex. Sorry but python is new to me. I see its pedantic about white spaces

from rs.

Give me some time to figure it out... In the meantime if you want to chat, maybe #highaltitude on Freenode IRC is better than using a github issue log as a chat thread :-P

from rs.

I think this machine wont support, I tried IRC before but it all hung, maybe I have to many anti five eyes and BB blocks installed in my network here. but emails fine, sip voice is better and my normal, are you geared up to run a sip client there? Yes git hubs not the place.

from rs.

I think, json-output is already in meisei_ims. But if you wait till tomorrow, I'm including a serial number right now, although I don't know which one is which (until we get some recordings+hardware_pics for confirmation).
I think the (main) serial number at frame_count mod 16 that is most frequent and the first number in this cyclic config-data, thus it should be the most appropriate.
Since that data is all float32, for aprs the 32bit-machine-representation could be used.

from rs.

After the frame-counter, there is constant data repeating every 64 frame-counts, all the numbers look like not-to-small not-to-big float32. Some are integers, one repeats every 16 frame-counts (smallest period).
[...] the one that repeats most often (mod 16) is F386 4AD5 (7010755 as float).
Could this be the serial number of the radiosonde?
In the recording above from 2019-08-21:

049DCE 3200 8E31 F39E 4AD5 0000 : 4AD5F39E -> 7010767
..
049DCE 3210 8E31 F39E 4AD5 0000
..

This is indeed the sonde number as printed on the label. Within the 64 floats #0...#63 it is repeated at positions 0, 16, 32, 48.
The other two parameters I've indentified are:
2 = serial number of the PCB
4 = serial number of the sensor boom

Regarding this other finding:

And also there is a 14-16 byte block numbered 0..3 that looks like config data, though sometimes the data in there seems shifted

What exactly is the place in the frame that you are referring to?

from rs.

Yes the meisei_ims decoder JSON output is ok as best I can see for now, I ran a sample DPS sonde wav though it in auto_rx 2 nights ago and and it went through to aprs.fi ok. As I recall I forced it in the c code to the JSON option, also pertaining to that ref the question about wav decode at real time speed and sample data rates.

Re the label serial on the sensor arm, I think the serial full data is on the big label on the polystyrene outer hopefully we will have that in the morning from Eko in Surabaya along with data from the sonde.

from rs.

Thanks! I see you have done some further work on Meisei radiosondes, did you have a hardware sample for confirmation?

4 = sn(sensor boom), so this is also a label, but on the sensor boom (below the sensor)? Like this one https://www.gruan.org/gruan/_processed_/2/5/csm_Meisei_IMS-100_01_2f58004c05.jpg ?
On pictures, could never read the label on the envelope, but the (main) serial number is on the foam envelope then?!

I think I have seen 4 different sn-like numbers 7xxx in the latest sample:
3200 : 00 # F39E 4AD5 : 0x4ad5f39e = 7010767
3202 : 02 # 8D52 4AE8 : 0x4ae88d52 = 7620265
3204 : 04 # 306C 4ADF : 0x4adf306c = 7313462
320E : 14 # 05E4 4AD9 : 0x4ad905e4 = 7111410
3210 : 16 # F39E 4AD5 : 0x4ad5f39e = 7010767
3220 : 32 # F39E 4AD5 : 0x4ad5f39e = 7010767
3230 : 48 # F39E 4AD5 : 0x4ad5f39e = 7010767

Maybe there are additional or aux sensors possible.

float32 for serial number is unusual, though if all the other config/calib-data for (P)TU is float32, maybe it makes sense to not mix the data types.

FB6230 .... .... 0300: PRNs ?

For ims-100 there is one GPS-block (FB6230) in even frames, and the same block in odd frames contains a subblocks with 12-16 bytes, labeled 0300..0303 (maybe the upper byte can be different) (i.e. a cylce of 4 subblocks). First I thought it would be config data until I saw (in longer recordings) that it is not constant. But it does not change much. And in the 0300-subblock, there are bytes mostly up to 0x20, the last bytes could be C1(C2...) or 00 (older samples). Sometimes there is a byte added or removed from the list. The numbers did match visible PRN-numbers as far as I checked.
e.g.
ims100_20190612_00Z_404000kHz_raw_cut.txt.gz
.... 0300 0103 080B 0E10 1216 171A 1B1F 20C1 C2C3
....
.... 0300 0103 0809 0B0E 1012 1617 1A1B 1F20 C1C2
(09 is added)
Although I'm not sure, it would make sense that the odd FB6230-block is also GPS data.
Maybe the other blocks contain sat-SNR?

from rs.

Included the serial number for --json output (for ims-100 only). For APRS the shorter 32bit-value is maybe more appropriate and recognizable in the raw data.
The serial number (ID) may take a few frames until it shows up, similar to DFM.

Frequency drift maybe be as bad as DFM-06/09, also I'm not sure if the baud rate is stable (not good for option -b and error correction).
Frequency correction is on the TODO list anyway; basically it works, some more testing.

from rs.

did you have a hardware sample for confirmation?

Yes. Not too long ago there were test launches of iMS-100 from Lindenberg, and most of them went down in Poland. One the Polish hunters was so kind to give me one of his sondes!

4 = sn(sensor boom), so this is also a label, but on the sensor boom (below the sensor)? Like this one https://www.gruan.org/gruan/_processed_/2/5/csm_Meisei_IMS-100_01_2f58004c05.jpg ?

Yes, this is the sensor boom serial number.

On pictures, could never read the label on the envelope, but the (main) serial number is on the foam envelope then?!

Exactly. And there's a third sticker on the bottom side of the PCB.

Regarding the GPS data:

The numbers did match visible PRN-numbers as far as I checked.

I did the very same test here before! :-)
I'm also convinced that index 03 contains GPS PRN's.

By the way, The byte before the index byte (the upper byte in 0300/0301/0302/0303) seems to be a bit field. I only saw bits 0 and 1 set so far. The GPS position is invalid if either bit is zero.
I had the iMS-100 in my car for some "test cruising"... When I drove under a bridge, the sonde would still report a position, but with bit 1 in the flag byte cleared. Bit 0 seems to be always on once the GPS module starts reporting data, which is about 10 seconds after powering up the sonde.

So far I haven't looked much deeper into the GPS fields. I agree with you that both even and odd frames contain GPS data. There is another observation which strongly supports this. The very last 16-bit word in the second block (FB6230) is a checksum for everything GPS related:

There are twelve 16-bit words in each block, lets call them B0[0...11] and B1[0...11]. Take the simple arithmetic sum of these 13 16-bit words: B0[10...11] ... B1[0...10], then B1[11] should be that sum!

This is the same in even and odd frames. As B0[10] and B0[11] contain GPS data at least in the even frames, the existence of the checksum indicates that it's all GPS data waiting to be identified :-)

For your information, the GPS module is a SONY brand, and has this marking:
SONY
D5431-02
812A08G 02

The CPU is a Renesas type RL78/G13

from rs.

Did you have to do some thing to activate the sonde after power down, the ones here from Surabaya apparently don't restart after a power down.

from rs.

The gruan document refers to the chip as "special modified for Meisei", its possibly a variant of the CXD5430 mentioned in this Sony press release.
https://www.sony.net/SonyInfo/News/Press/201302/13-022E/

from rs.

I've added your current meisei decoder and the updated dft_detect into the testing branch of auto_rx. A few notes/questions:

• Currently you emit IMS100-0 when there's no callsign. I'm using this is as a filter, i.e. only accept the telemetry when the number after the - is something other than a 0. This should be fine for now.
• I note that dft_detect returns a negative correlation score on the samples we have, indicating an inverted signal, yet I don't need to use the -i option to decode it using meisei_ims. Are you just auto-detecting the inverted signal?
• I've added a UDP input option to auto_rx. You can use this by running up auto_rx with: python auto_rx.py -v -f 401.0 -m UDP . auto_rx will then be listening on UDP:localhost:50000 for lines of JSON. So you could feed in JSON data using cat samples | ./decoder --json | nc -u localhost 50000. Note that I have disabled all callsign filtering when in UDP mode, so BE CAREFUL! If the uploaders are enabled, then any new callsign you feed in will automatically have a payload document be created on the Habhub tracker, which could lead to bad things if you start feeding in a lot of different callsigns. At the moment APRS uploads won't work with UDP mode, since without knowing the callsign structure I can't produce a shortened callsign.

from rs.

Apparently the sonde can only be restarted if it hasn't been allowed to slowly run out of battery before. If the battery voltage drops below a certain threshold when the sonde is operating, it seems to set a permanent flag which prevents a restart.

My iMS-100 sample was recovered in time to disconnect the battery before that "self destruct" could happen.

This was found out by the Polish guys who managed to collect quite a few of these sondes.

from rs.

@einergehtnochrein
Thanks for the information!
I have seen this checksum in the GPS block, was going to investigate that. The gruan-document said xor-sum, however the document seems to describe a exchange-format that is a bit different.

I got some audio of the last campaign in april.
And the first samples in 2015 from the 2014/10 tests at Lindenberg, also with RS-11G. Perhaps the older frame data format (RS-11G) is not relevant anymore, I included a check that tries to separate these two, but I'm not sure. In the non-GPS blocks for ims-100 the two subframes each second have 30C1 or 31C1, resp.
https://github.com/rs1729/RS/blob/master/meisei/meisei_ims.c#L48
All ims-100 that I know have C1 in the lower byte. The non-ims100 recordings showed A2 or something else lower than C1 there. Maybe it is a kind of frame/firmware version?

from rs.

Just saw that the C1, C2, C3 in the list of PRN's make sense, as they are used by the Japanese QZSS system.
Seems like the availability of QZSS extends from Japan via South East Asia further to Australia.

from rs.

@vk3-hca
Maybe they use a custom GPS sentence.
Meteomodem replaced the M10 GPS chip. The new Sierra Wireless Airprime XM1110 offers custom GPS sentences, and I think they use this for the M10, so the mcu gets a custom GPS sentence with all the GPS information needed in a compact short sentence.

@darksidelemm
Yes, the serial number is not in every frame, so (like DFM) until the SN is received, the variable has the old value, at start it is initialized to 0. Would "IMS-XXXX" be better as long as sn==0 ?
For APRS I was thinking about the 32bit value that makes the float-SN, but the hex-representation would make 8 characters... Since "IMS-" is 4 characters, the last 5 digits of the serial number might be enough.

The negative score does not matter for Meisei, same as M10 and LMS6-403 (differential coding).

btw: LMS6-403 is 4800 baud and convolutional code. The 1680MHz-Mk2a coding is plain 8N1 9600 baud.

from rs.

@einergehtnochrein
Beidou has also C-PRN numbers, however would be strange if always C01 is visible, and China is not Japan...
So the QZSS data could be the "SBAS" in the product description that @vk3-hca mentioned.
The Lindenberg recording shows more 00-bytes, though there is a C1. Maybe from 7000m altitude, from ground the QZS-1 is some 20 deg below horizon.

Lindenberg -> Poland
Sometimes there have been photos of Lindenberg radiosondes in a polish forum, but I didn't see Meisei photo. And now the forum has closed the doors I believe ...

from rs.

Auto_rx test on new dft_detect and decoder darksidelemm added into auto_rx yesterday detected and attempted to decode signal just above the noise floor from 250Km distant.

from rs.

The signal was detected as meisei, but it didn't decode frames? If the signal is weak, the old decoder is not so good. I have another version that detects the header the same way as dft_detect:
https://github.com/rs1729/RS/tree/master/demod/mod
Compile:
gcc -c demod_mod.c
gcc -DINCLUDESTATIC meisei100mod.c demod_mod.o -lm -o meisei100mod

usage:
./meisei100mod --ecc -v <audio.wav>
(--json optional)

(Hopefully the baud rate is not off)

from rs.

Will switch auto_rx to using this tonight...

Just to confirm, the IMS100 is transmitting 2400baud AFSK ?

from rs.

It's 2400 baud FSK.
(Biphase-S coding, so the bit rate is 1200 bit/s)

from rs.

from rs.

The deviation is more than +/- 3.5 kHz, so with 2400 symbols/s that should be a modulation index of 3 (given that I looked up the right definition).
Quite unusual is that there seems to be no baseband filtering at all. A matched filter in the receiver then means no filter...

from rs.

I made those recordings with SDR# on WES7, the filter setting was Blackman-Harris 4, 11.5kc, order1.

from rs.

Yes, I calculated a modulation index around h=2.8 or higher.

Looks like high BT (not much pulse shaping/filtering).

And the bandwidth is indeed higher than the DFM-bandwidth, but similar parameters, the spectrum looks similar, too.

from rs.

@darksidelemm
would it be better to output (json) "IMS-XXXX" as long as the ID is not received?
#14 (comment)

from rs.

from rs.

auto_rx testing branch now uses meisei100mod (and lms6Xmod)

from rs.

WAV and IQ recordings from this mornings DPS sonde, SDR# and WES7 misbehaved worse than normal today, its not as good as it should be. I suspect the QSB is related to that issue.

Filter changed from 12kc to 15kc at 01:00Z

As above by darksidelemm meisei100mod was used today as well, some idea of the good results in screen grabs.

https://drive.google.com/open?id=1vCE6bzrEZBsTMY75HNyxcPo12JMZar0e

from rs.

https://tracker.sondehub.org/?sondehub=1#!mt=osm&mz=10&qm=3_days&mc=-8.45444,114.79632&q=RS_IMS*

from rs.

from rs.

I included the gps checksum (c.f. #14 (comment)).
For reliable --json output this can be important to check.
In the latest upload I found 6/1489 frames where the BCH error correction (and parity bit check) suggested, the frame could be repaired, but the checksum was false.
These frames had several BCH-blocks with 2 errors, so if there are blocks with 0 or 1 errors in the same frame, it could be that there were (corrected to) wrong codewords. It is not as likely to get wrong codewords (i.e. not the codeword that was transmitted) as it is for DFM, but the distance between codewords is still not very large, so the checksum is useful, if frames with corrected errors are to be used. If a frame would only be considered when all the codewords had no errors in the frame, the probability for wrong decoding would be very low, but the gain of error correction would be gone. (For DFM a checksum/crc would be really helpfull.)

from rs.

I've rebased auto_rx's testing branch to your latest meisei100mod. @vk3-hca can you run a git pull, and then re-build the binaries (./build.sh).

from rs.

APRS:
The serial number has (6-)7 digits now, in hex with 6 nibbles it could up to "16777215" in base 10.
Maybe APRS-ID: IMSxxxxxx with 6 hex nibbles is good enough?

from rs.

Exactly what I've got implemented right now :-)
https://github.com/projecthorus/radiosonde_auto_rx/blob/testing/auto_rx/autorx/aprs.py#L85

from rs.

I updated and rebuilt the testing branch after your update to meisei100mod last night for this morning, you have updated since?

from rs.

Correct, based on the updates @rs1729 pushed early this morning.

from rs.

Ok will do.

from rs.

ok! didn't see that.

from rs.

I think I can safely say the frequency drift is the sondes, there is an unknown narrow signal on 404.3 the normal Surabaya sonde channel. Out on the tower the auto_rx its trying to decode it as an RS92 without success.

Its still centered after 40 mins on SDR# with out re-tuning which proved the drift is not the SDR receive system here.

https://drive.google.com/open?id=1bXaidwYDc_gSuDWopx0TcYbdGh9KTiSf

from rs.

RS92 decodes fine:

./rs92mod --ecc --crc --vel -e brdc2550.19n SDRSharp_20190912_010420Z_403409008Hz_AF.wav
[ 5086] (L3933021) (2019-09-12) Thu 01:05:02.360 lat: -7.66156 lon: 114.03305 alt: 15682.5 vH: 10.5 D: 265.2 vV: 4.4 # [0000]
[ 5087] (L3933021) (2019-09-12) Thu 01:05:03.360 lat: -7.66158 lon: 114.03294 alt: 15688.5 vH: 10.7 D: 264.8 vV: 4.6 # [0000]
[ 5088] (L3933021) (2019-09-12) Thu 01:05:04.360 lat: -7.66158 lon: 114.03280 alt: 15691.1 vH: 12.0 D: 267.1 vV: 4.3 # [0000]: fq 403410
[ 5089] (L3933021) (2019-09-12) Thu 01:05:05.360 lat: -7.66157 lon: 114.03268 alt: 15694.3 vH: 12.7 D: 265.5 vV: 4.6 # [0000]
[ 5090] (L3933021) (2019-09-12) Thu 01:05:06.360 lat: -7.66159 lon: 114.03258 alt: 15698.9 vH: 12.4 D: 264.6 vV: 4.3 # [0000]
[ 5091] (L3933021) (2019-09-12) Thu 01:05:07.360 lat: -7.66161 lon: 114.03248 alt: 15705.7 vH: 11.6 D: 262.3 vV: 4.2 # [0000]
[ 5092] (L3933021) (2019-09-12) Thu 01:05:08.360 lat: -7.66161 lon: 114.03240 alt: 15708.9 vH: 10.6 D: 263.0 vV: 3.7 # [0000]
[ 5093] (L3933021) (2019-09-12) Thu 01:05:09.360 lat: -7.66162 lon: 114.03230 alt: 15712.2 vH: 10.1 D: 261.9 vV: 4.0 # [0000]
[ 5094] (L3933021) (2019-09-12) Thu 01:05:10.360 lat: -7.66162 lon: 114.03220 alt: 15715.2 vH: 10.6 D: 267.6 vV: 3.8 # [0000]
[ 5095] (L3933021) (2019-09-12) Thu 01:05:11.360 lat: -7.66162 lon: 114.03211 alt: 15718.8 vH: 11.2 D: 270.9 vV: 3.6 # [0000]
[ 5096] (L3933021) (2019-09-12) Thu 01:05:12.360 lat: -7.66163 lon: 114.03199 alt: 15722.5 vH: 12.7 D: 275.1 vV: 2.8 # [0000]
[ 5097] (L3933021) (2019-09-12) Thu 01:05:13.360 lat: -7.66161 lon: 114.03188 alt: 15723.2 vH: 12.8 D: 276.7 vV: 3.7 # [0000]
[ 5098] (L3933021) (2019-09-12) Thu 01:05:14.360 lat: -7.66159 lon: 114.03178 alt: 15728.8 vH: 11.5 D: 275.7 vV: 3.7 # [0000]

./rs92mod --ecc --crc --vel --gpsepoch 2 -a almanac.sem.week0022.405504.txt SDRSharp_20190912_010420Z_403409008Hz_AF.wav
[ 5086] (L3933021) (2019-09-12) Thu 01:05:02.360 lat: -7.6585 lon: 114.0293 alt: 15412.4 vH: 10.6 D: 265.7 vV: 4.5 # [0000]
[ 5087] (L3933021) (2019-09-12) Thu 01:05:03.360 lat: -7.6585 lon: 114.0292 alt: 15418.5 vH: 10.7 D: 265.3 vV: 4.7 # [0000]
[ 5088] (L3933021) (2019-09-12) Thu 01:05:04.360 lat: -7.6585 lon: 114.0290 alt: 15421.2 vH: 12.1 D: 267.5 vV: 4.5 # [0000]: fq 403410
[ 5089] (L3933021) (2019-09-12) Thu 01:05:05.360 lat: -7.6585 lon: 114.0289 alt: 15424.5 vH: 12.7 D: 265.9 vV: 4.7 # [0000]
[ 5090] (L3933021) (2019-09-12) Thu 01:05:06.360 lat: -7.6585 lon: 114.0288 alt: 15429.3 vH: 12.5 D: 264.9 vV: 4.4 # [0000]
[ 5091] (L3933021) (2019-09-12) Thu 01:05:07.360 lat: -7.6585 lon: 114.0287 alt: 15436.1 vH: 11.6 D: 262.7 vV: 4.3 # [0000]
[ 5092] (L3933021) (2019-09-12) Thu 01:05:08.360 lat: -7.6585 lon: 114.0286 alt: 15439.4 vH: 10.6 D: 263.4 vV: 3.8 # [0000]
[ 5093] (L3933021) (2019-09-12) Thu 01:05:09.360 lat: -7.6585 lon: 114.0285 alt: 15442.9 vH: 10.2 D: 262.4 vV: 4.1 # [0000]
[ 5094] (L3933021) (2019-09-12) Thu 01:05:10.360 lat: -7.6585 lon: 114.0284 alt: 15446.0 vH: 10.7 D: 268.1 vV: 3.9 # [0000]
[ 5095] (L3933021) (2019-09-12) Thu 01:05:11.360 lat: -7.6585 lon: 114.0283 alt: 15449.7 vH: 11.3 D: 271.3 vV: 3.7 # [0000]
[ 5096] (L3933021) (2019-09-12) Thu 01:05:12.360 lat: -7.6585 lon: 114.0282 alt: 15453.5 vH: 12.7 D: 275.4 vV: 2.9 # [0000]
[ 5097] (L3933021) (2019-09-12) Thu 01:05:13.360 lat: -7.6585 lon: 114.0281 alt: 15454.3 vH: 12.8 D: 277.0 vV: 3.9 # [0000]
[ 5098] (L3933021) (2019-09-12) Thu 01:05:14.360 lat: -7.6585 lon: 114.0280 alt: 15460.0 vH: 11.6 D: 276.1 vV: 3.8 # [0000]

The almanac does not have the full gps-week, for data after april 6th 2019 you set gpsepoch=2 to get the right date.

The brdc/ephemeris doesn't need that, it has the full gps-week in the data.

Without almanac/brdc you can still decode raw data or frame-number, sonde-id and time of week.

@darksidelemm
RS92 reports frequency: 403410kHz.
The sdr#-recording is on 403409kHz.
auto_rx reports: "INFO:Decoder #0 RS92 403.400".
Is it trying to decode on 403.400 (20kHz steps)?

from rs.

Sorry, I missed the bus here, that RS92 decode was with the auto_rx RS92 decoder? Not the RS git?

I would take no notice of my SDR# frequency, I had a 1 ppm shift in the sdr config and maybe a -910 shift applied. As it does not transmit I have concentrated on keeping it centered in the filter rather than what exact frequency SDR# thinks it might be.

I think at the time auro_rx was set with 403.400 as a whitelist because Surabaya normally is on the frequency. But I have not set anything knowingly which could define 20kc steps in Auto_rx.

from rs.

And of course its 2 different RTL_SDR, one in the pi, one -n the WES7dirtbox.

from rs.

Denpassar Sonde wav and IQ files from this morning are on
https://drive.google.com/open?id=1gYFr7KF4Zfh7Zyb9cQxQD2lUBKvFf6un

from rs.

Denpassar Sonde raw IQ files, some IQ decode grabs and log from this morning are on
https://drive.google.com/open?id=1v-Uel8mMJLCahNioHKcahOiZnQwjOce2
Intention being sonde drift analysis on decent.

from rs.

from 13 days ago :
APRS: The serial number has (6-)7 digits now, in hex with 6 nibbles it could up to "16777215" in base 10.
Maybe APRS-ID: IMSxxxxxx with 6 hex nibbles is good enough?

I think next week next Wednesday , with 2 independent systems decoding the sonde serial, 2 different sondes in different places uploading to APRS second tier servers without individual Serial Number callsigns will be an issue on APRSIS?

from rs.

Serial numbers for the iMS sondes is a solved problem, shouldn't be an issue.

from rs.

They don't appear on APRS.fi on sondes I decode, but they do on sondehub, I have a balloon and no name or call (YD9ACN) , Eko (YG3CJY-11 in Surabaya with a straight decode and upload script) has the ID SONDEBKMG I don't think he has the latest decoders in use. Next week will be 2 from one and Java one Bali via auto_rx?

from rs.

This is on aprs. No serial number, but no "auto_rx" in the comment.
@vk3-hca
Is this produced by auto_rx? Latest update?

@darksidelemm
The latest iq-uploads have longer recording with 32kHz bandwidth, so you can see the drift. (The frequency offset is sometimes manually reset.)
With
./meisei100mod --ecc -v --iq2 --lp --dc
it decodes fine. If the initial offset is not too big, it should track the signal over several kHz drift.
For FM-audio it would be more difficult, since the filter would have to track the signal. If the FM-IF filter is choose too wide, the FM-audio is too noisy.

from rs.

auto_rx should support uploading of IMS sondes to APRS from since when I added the IMS decoder. However I have had issues where the radiosondy.info APRSIS server has not been forwarding packets correctly, so maybe change the the aprs_server setting to rotate.aprs2.net and it might be more reliable.

OK, I'll look at switching the meisei decode chain to using your IQ setting. Really need some high-SNR samples to do the PER vs Eb/N0 testing with.

from rs.

Maybe the recording here
#14 (comment)
is better for testing.

Perhaps the iq-decoding for ims100 needs some fine-tuning, but the difference to FM-decoding should be minor.
The DFM decodes with --iq2 better, M10 somtimes also better, RS41 not much difference. (higher modulation index is better for decoding.)
RS92-NGP was good with --ngp --iq3 (different sampling point, not so important)
For iq-decoding there are more parameters and maybe different kind of receivers can produce different result.
I didn't test rtl_fm decimating to 48kHz. For FM you decimated to 12kHz (so it is filtered) and upsample then?
For IQ I think it should be better 48kHz raw iq, 32kHz can work with slower radiosondes like dfm or meisei.
Filtering can be done with --lp, I hope it is still fast enough on raspi.

from rs.

Yes, for FM I'm using lower rates. This is because the FM filter bandwidth and the output sample rate of rtl_fm are coupled together. For IQ not an issue. Will probably use 48 kHz - this is what I'm feeding into fsk_demod for most sondes at the moment, though for RS92NGPs I up that to 96 kHz. (fsk_demod only looks for the FSK tones in the positive part of the spectrum, its a limitation I hope to fix at some point)

from rs.

@einergehtnochrein Would it may be possible for you to provide us with a high-res PCB scan of the iMS-100? That would be really awesome!

from rs.

I have put an annotated photo up here for you, give me a couple of days to find the scanner and I will add something better.

https://drive.google.com/open?id=1j549gR_icBnl1TCmqAOJfoj7ziADvU0Z

H.

from rs.

@bazjo I have no equipment to do PCB scans the way you do, but I hope you appreciate the attempt...
https://www.mediafire.com/view/m9aq87fdqwtewuw/ims100.png/file

from rs.