Sensor boom error MEAS frequency invalid after flashing RS41-NFW firmware

[Petya64]

I tried 3 different fresh and well working (with Vaisala FW) sonde and the result are the same: none of them found the boom!
Please give some narrowing solution how to fix T, RH measurements.

HW: new pcb versions, RSM4x4 AND RSM4x5 (based on MCU STM32L412RBT6 LQFP64)
Uploaded RS41-NFW Version 55 (public, stable), without any changes with Arduino IDE settings:
UpLoad method: OpenOCD STLink
Motherboard: GenericSTM32L4 series,
Board Pert GenericL412RBTxP
Result:
...xPack Open On-Chip Debugger 0.12.0+dev-01850-geb6f2745b-dirty (2025-02-07-10:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 0
[stm32l4x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bff8 msp: 0x20028000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

---

HW Reset (battery off and on)

Serial monitor:
12:42:30.139 -> [info]: Serial interfaces initialized
12:42:30.139 -> [info]: ADC resolution se[WARN]: Main temperature hook sensor boom error! MEAS frequency invalid. The hook may have snapped.
12:42:39.612 -> [info]: Humidity module heating power is 0/500 .
12:42:39.688 -> [info]: Automatic humidity module temperature calibration - extHeaterTemperatureCorrectionC = 177.32C
12:42:40.259 -> [info]: Automatic temperature calibration and correction complete
12:42:40.259 -> [info]: Starting humidity calibration...
12:42:40.259 -> [info]: Entering zero-humidity calibration...
12:42:40.259 -> [WARN]: The humidity module WILL GET HOT! During 0-humidity check, please keep the device in a stable environment, with little to no wind, RH < 70%, temperature > 0C and don't touch, submerge, blow, lick or do anything with the sensor.
12:42:40.291 -> [info]: References heater power has been set to 0
12:42:46.821 -> [WARN]: Main temperature hook sensor boom error! MEAS frequency invalid. The hook may have snapped.
12:42:50.381 -> [info]: References heater power has been set to 0
12:42:56.912 -> [WARN]: Main temperature hook sensor boom error! MEAS frequency invalid. The hook may have snapped.
12:43:00.529 -> [info]: Humidity module temperature = 1.62*C
12:43:00.529 -> [info]: Humidity module heating power is 500/500 .
12:43:00.756 -> [info]: Not taking measurement - temperature significantly too low.
12:43:00.756 -> [info]: References heater power has been set to 0
12:43:07.283 -> [WARN]: Main temperature hook sensor boom error! MEAS frequency invalid. The hook may have snapped.
12:43:09.544 -> [WARN]: External humidity heater temperature sensor error! MEAS frequency invalid.
12:43:11.676 -> [ERR]: The sensor boom seems disconnected!
12:43:11.676 -> [info]: Humidity module heating power is 0/500 .
12:43:14.453 -> [ERR]: Sensor boom measurement error (check boom and connection) - exiting calibration...
12:43:14.453 -> [info]: Exiting calibration.
12:43:14.453 -> 0RH_freq | 100RH_freq => 0.00 | -1100.00
12:43:14.453 -> [info]: GPS is ON
12:43:15.453 -> [info]: GPS settings are being initialized...
12:43:15.485 -> [info] Setting the Airborne 1G (6) GPS dynamic model...
12:43:16.517 -> [info]: GPS settings done
12:43:16.517 -> [info]: Exiting setup and entering main program loop...
12:43:16.517 -> [WARN]: gpsFix - gps isn't locked on position, give sky clearance, waiting for fix...
12:43:16.549 -> [info]: GPS is ON
12:43:17.805 -> [info]: GPS data obtained and updated

[Nevvman18]

Hi, sorry for such a late response, I'm very busy lately. It may be a dumb question, but did you try also with other sensor booms? They are fragile and often get damaged, and the damage isn't always visible to the naked eye. I see however that you tried them with vaisala fw and they worked.
By analyzing the logs it looks very weird, I can't really help because it looks like the sensor or circuitry failed and the microcontroller doesn't receive any data from them, but it is inconsistent with the correct operation using vaisala fw. I will think about this issue

Best and happy new year
Franek

[Petya64]

Hello.
We (a former weatherman and a current electric engineer) tested it on more than one boards (and we collect RS41 sondes from the fields regularly). The booms work correctly, we measured it with a multimeter. We also looked at the Frequency measurement with an oscilloscope. The correct frequencies are there, but we think they weren't measured correctly in the code. So the hardware is checked and it's working correctly. We also have it on more than 1 sonde.
The evaluation of the code in "getSensorBoomPeriod" takes longer than one clock of the measurement, which resulted skipped edges. Also we noticed when the GPS was enabled, the code also skipped edges. Therefore the reported frequency was significantly lower than the frequency measured with the oscilloscope. We've confirmed this with some debug prints for the measured frequency.
We've been looking into the way to enable hardware timers to measure the frequency, but that is a fundamental change to the code.
Changing the timeout from micros() to millis() speeds up the code, because evaluating that takes less time.
First question is, are you using a specific compiler setting to speed up the execution of the code on your board? Or the default Os?
Second question is, would you accept some contribution to the code from us? We made the measurement work more reliably with some code changes.
Best wishes,
Petya64 and tszaboo

[Nevvman18]

Yes, I would be very grateful if you provided your changes to the code! I'm looking forward to updating the measurement code, even though I don't know why it didn't work initially with yours (usually it works great with every sonde).
The compiler option I use is the default smallest -Os, I didn't check the other options, I'm not sure if the code would still fit to the older revision flash.

Franek

[Nevvman18]

Yes I also observed the weird behavior with GPS enabled, the reported values seem to oscillate a bit and I wasn't able to track down the problem. I'm soon to release a new version with some large updates, so it would be very helpful for us to implement a better way to read the sensors.

Best,
Franek

[Nevvman18]

The sensor readout timing in relation to GPS messages reading/receiving seems to have effect on the noise, in the v56 update (which focused on different things) I timed them differently and the noise seems sometimes gone and sometimes still prominent, so 1/3 success. I assume Your solution may be better, as I'm trying my best to get the noise even more down. I'm looking forward to hear news from you.

Best,
Franek

[Petya64]

We noticed a few things.
First we isolated the measurement and turned off everything else for some testing, printing the results.
By the looks of it, using period instead of frequency is very linear. We connected a resistor decade box in place of the PT1000 and simulated several temperatures. The linearity between 750 and 1150 ohm is very high, 99.99% according to the curve fitting. See measurement values below.

The second thing we noticed was the reference resistors on the board. The documentation was 1010 Ohm, while we measured it as 1100 Ohm.
What we are trying to do now is modifying the code to use the built in timer-counter. This way, without using interrupts, we can make a more robust measurement code. Because even if other peripherals (like GPS) cause interrups, the edges will still be detected. And no timeout checking is necessary, because the measurement would just be exactly the same time, even if the boom is damaged or missing.

So to summarize: Use period instead of frequency, we get very accurate and linear results. Once we have a working code, we'll try to send it to you.

Period	Frequency	R nominal
1,67858067275499E-05	59574,14	1200
1,6111660250198E-05	62066,85	1150
1,54224763777785E-05	64840,43	1100
1,47369100501748E-05	67856,83	1050
1,40560129304074E-05	71143,93	1000
1,33888219670938E-05	74689,17	950
1,27087362267483E-05	78686,03	900
1,20495835543428E-05	82990,42	850
1,1397938979082E-05	87735,16	800
1,07274164551488E-05	93219,09	750

[Nevvman18]

Wow, all your work sounds awesome! I wouldn't be able to do this all alone, it is a very informative write-up. I'm looking forward to see the modified measurement code, that will use the hardware timers, I had some trouble implementing it some time ago. Your contribution to the project is very helpful, thanks!

Franek

[Petya64]

We are measuring 1000 Ohm and 1200 Ohm at room temperature on the two "supposedly" PT1000 sensors. Which means that they are for sure not PT1000s, but some other measurement devices. The two resistor values can be measured on the sensor boom between some pins as well with a multimeter.
If you have a pinout of the sensor boom, that would be very useful, to confirm we are measuring the right resistors.
Our code with timers and counters seem to work well, we confirmed it with the resistor decade box.
I can do some measurement on a boom next week, by placing it on a soldering reflow plate and recording a few values.

[Nevvman18]

Yes, I've seen that the sensor booms have different "offsets" of resistance and they aren't factory-like PT1000, sometimes off from the actual temperature (usually 1-4°C).

The hook sensors are quite similar so the offsets aren't that big (mentioned 1-4°C), but there is also another PT1000 sensor, built into the ceramic humidity module itself. They are much worse in terms of resistance repeatability, usually requiring 5-25°C of offset correction. Maybe that's what your measuring? I'm not sure.

However from my tests, even though the resistance is almost always slightly off, the linearity of each sensor is ok, allowing use of constant linear corrections. All flights that I or my friends have done were quite accurate, compared to an actual flight (even German weather service flew factory sonde and RS41-NFW, the error was 0.5-3.5°C usually). That's why I implemented temperature calibration that calibrates the offset of both, and the results seem to be rather accurate (more than I would assume initially).

I'm very interested in the timers code, as I don't have the knowledge of them. Also, does the code work the same between both old and new revisions?

I also don't have the sensor booms pinout available, IIRC you can check the bazjo's Radiosonde hardware repo, which may have a schematic of it. All that I'm sure is that the pinout stays the same between revisions.

Best,
Franek

[DadoRdz]

A year and a half ago, I prepared a fairly detailed internal document describing how the RS41 probe works, especially the input electronics with oscillators for measuring temperature and humidity and the associated reference elements for calibration. The document also contains details of the sensor design and the layout of the pins on the probe connector for that boom with the sensor. The document is quite large (39MBy), so I cannot upload it directly to this site. It is also written in Croatian, but in today's age of artificial intelligence, this should not be a significant limitation. If you would like me to share this document, please let me know and we will try to find a way to distribute it.

[Nevvman18]

Hi, if you could share it with us we would be very grateful. Maybe try uploading and sharing it on WeTransfer (my mail is in my GitHub profile) or Google Drive?

Thanks for contacting me,
Franek

[Petya64]

We agree, it wold be very handy to see it here, we think here is a 2 GB space per user or so.