AnemometerTX Gust

[ghost]

Any thoughts on what might be the best way to implement gust reposting in the AnemometerTX example with the limited 328 ram?

[kobuki]

Do you mean gust reporting? Standard gust reporting is the highest wind speed the last 10 minutes. You don't really need much memory for that. But this tends to be the task of the weather monitoring SW, not the firmware, though definitely possible.

[ghost]

Oops, typo. Sorry. Yes, gust reporting.

For hardwired transmission or wireless transmission with delivery confirmation, I agree that wind gust should be handled by the monitoring software or data logger.

However, for "send and hope it arrives" wireless transmission like what Davis uses, gust really needs to be reported by the firmware as the odds of lost packets are high.

I imagine this is why Davis has the x90 wind gust message. I'm trying to wrap my head around that message and how to implement it.

[ghost]

Basically, I have a board design that I can adapt into an open source and fairly cheap to assemble transmitter that would allow a wide range of RM Young anemometers to be used with Davis setups. However, for it to be worth the effort, I really need to figure out how to transmit the gust message.

[kobuki]

The gust is indeed reported by the SIM but it's not used by anything, as far as I know. The packet loss is way smaller than you might think. In normal circumstances, reception quality is near 100% [received/(received+lost)*100]. Mine averages at 99% for 2 stations (one wind, one ISS). That shouldn't cause any problems, and in practice it really doesn't.

[kobuki]

Basically, I have a board design that I can adapt into an open source and fairly cheap to assemble transmitter that would allow a wide range of RM Young anemometers to be used with Davis setups.

This sounds good!

[kobuki]

BTW, if you want to be proper and transmit gust, you can find how it's emitted in ISSRx.ino. It's basically a negative index that points to the highest wind speed in the last 10 measured values or so. If you log a few hours worth of packets in windy conditions, you'll see how it's encoded in the payload. It's discussed in more detail at wxforum, if you really need that, I can dig this up, but actually, it might not worth the extra effort.

[ghost]

I'd really like to do it properly and have the gust transmitted. Is this something that would be fairly easy for you implement in your example sketch? Is so, I'd be happy to "sponsor" this addition. $100 USD via PayPal?

[kobuki]

No need for sponsoring, the problem is always the free time I can spend on it. I can add the feature (even though I don't see much sense adding it), but you're also welcome to create a PR. You can build your HW regardless and later flash with new FW. If you plan to use the sketch as-is, it's not really optimized for low power usage and it's not even using timers, so it needs a redesign. Also, the transmission from the RFM to the Davis receivers can be flaky sometimes, mainly on 900 MHz bands. Transmission functionality is not as well developed as the receiver side.

[ghost]

Fair enough. I've sent the board design off for manufacturing. I'll have it in a week or so and will do some testing.

Do you happen to have a link to the topic on wxforum where the wind gust message was discussed?

[kobuki]

Sorry, I wasn't able to find the discussion on the 0x9 packet format. However, it's pretty simple, as I've noted. If you're able to log a stream of packets from your station with a Davis anemometer, you can confirm the payload data values.

[ghost]

Well, you were definitely correct about the transmission in the 900 Mhz bands being flaky. Only about 6% of the packets appear to be received by the davis hardware. So far I've determined that most of the packets being received are on US channel 11 (903.888).

I think the problem is either timing related or the band table may be off. Do you know where the band tables came from?

[kobuki]

The table is from DeKay, and it worked for him and other users running his old code. It's definitely timing related, but I haven't been able to fix it, since I don't have a US transmitter. It would be highly appreciated if you or someone else with a US SIM board would be able provide a patch. Though it's not impossible the table is a bit of for some channels, but not very likely, either - and that in itself shouldn't cause problems because the receiver has pretty good AFC.

[ghost]

I'll play with the timing and see where I can get. It definitely feels like something isn't syncing up just right.

[ghost]

Alright, a couple of things:

1) I just realized I wasn't clear earlier. Your code and all three of my rfm69 boards receive in the 900Mhz US band just fine. Both from Davis devices and other rfm69 boards transmitting. Reception is always 99-100%. The problem I'm having (well, had. See below) is transmitting so that Davis receivers (Console and WeatherLink Live) sync with the rfm69 radio and receive packets.

2) I believe I've solved the transmitting issue. There's nothing wrong with your code. The trick is that you have to tune the frequency correction and time base for every single rfm69 radio and microcontroller.

It seems rfm69 radios combined with your code receive packets sent slightly off frequency and/or time just fine. However, the radio used by Davis does not. The transmit timing and the frequency has to be spot on for the Davis code to sync with the transmitter and receive 99-100% of the packets. Apparently either the radio used by Davis has a more accurate clock or they are calibrated with offsets (either by davis or during radio manufacturing).

Finding the sweet spot for each rfm69 board is a bit of a pain but what makes it worse is that the time base setting appears to need to be adjuster per transmit ID. For example, on one of my boards, the following works for ID 7 (Davis 8):

radio.setFreqCorr(-21); radio.setTimeBase(998110);

However, in order for ID 0 (Davis 1) to work, the time base has to be adjusted (leaving it at 1000000 or 998110 results in no packets making it through):

radio.setFreqCorr(-21); radio.setTimeBase(999000);

Anyway, now that I have the example code working I can move forward with my project. Thanks for all the help! I'll start a thread on wxforum once I have things up and running.

[kobuki]

Thanks for sharing your findings. Do you think there's anything to be added to the code to alleviate the issue? Some kind of automatic time offset correction or such thing. At one point I played with adjusting delay times based on actual reception delays, but it failed. I didn't spend too much time with that, though.

Another important thing is that the anemometer transmitter sketch is not really suitable for general use. It uses simple delay loops and simplistic handling of events. The library is using timers and should be more adequate. Additionally, I think it's wiser to use an accurate, XTAL based board. The Moteinos use a resonator.

[ghost]

I'm honestly not sure how you could resolve the timing issue via code without an external source for calibration. I do have some good news though. Yesterday I was testing with three Moteino boards. Today I'm testing with three Adafruit Feather 32u4/RFM69HCW boards. The 32u4 feather boards have turned out to be a bit better in regards to timing. They'll actually get an initial sync with the Davis receiver without any time offset. However, the timing is off just enough to eventually lose sync. These 32u4 boards seem to be quite consistent though as applying 999500 as the time base works for all of them. I have a few more on the way to confirm if this will work as a universal offset for these boards.

Unfortunately, I have found zero consistency in the frequency offset needed for the RFM69 radios. At least an SDR makes it quick and easy to figure out the offset needed.

I've had one transmitter running for 24 hours now with the receiver at a "real world" distance and reception is around 95-97%. I've noticed that the packets that don't make it through are always on the same channels. If I adjust the frequency offset very slightly, the channels with missed packets will change. I'm not sure if it's just a matter of setting a very precise offset or if some of the channels in the US band table are a tiny bit off. Although, 95-97% is likely good enough as long as I implement the gust message.

As for the anemometer sketch, I'm just using it for testing. I've removed all of the Davis anemometer bits and just have it sending sequential wind speed and direction values for testing. I'll write a sketch for my project from scratch using the library.

BTW, I've noticed zero reception/syncing difference between a VP2 console and a WeatherLink Live. I'm now just using the WLL since I can have up to eight boards running my test sketch. I think it's a bit funny that Davis is so tight-lipped about their RF protocol and yet the WLL is an excellent development tool.

[kobuki]

Thanks again. Interesting - a couple of years ago another user was successful in sending packets with a near 100% ratio using the same fiddly method you devised (tiny adjustments to clock and frequency) so I hesitated to recommend it, since it's not a general solution and takes a lot of time, and I thought it's a problem with a unique, individual setup. But you eventually arrived at the same solution so it can probably concluded that the tight scheduling and frequency settings of the US band make the Moteino+RFM69 combo either unsuitable or I need some complicated addition to the code for prior manual calibration, something I pretty much want to avoid. The purpose of the libs and sketches is to make an easy to use hobbyist tool for the Davis stations and receivers. OTOH - the EU band works perfectly, any time. Weird.

But based on the info above I already have a few ideas I want to try as I have more time. Which is a bit far off...

[ghost]

One possible solution for the timing might be to use the alarm output from a real-time clock (DS3231, etc) instead of the internal timer.

One thing I'm concerned about with the internal timer is temperature fluctuation affecting the timing after getting an offset dialed in. I'm going to have to do some testing with a transmitter outside to see if this is a problem or not.

For my project, I've always had a plan B which is to emulate the Davis anemometer with a pulse generator and a digital potentiometer. I'm just trying to avoid going that route because Davis can't claim a warranty violation if the 3rd party device isn't physically connected to the Davis hardware. There's not much Davis can complain about if their hardware receives and processes signals sent in the ISM band.

[ra1nb0w]

I have read this thread with great interest because I built an anemometer TX (EU frequencies) and it is deployed under the roof. It works but from time to time the console can't receive packets. Switching off and then on it generally fix the problem.

Do you think that the issue can be the same and fixed with setFreqCorr and setTimeBase using a good SDR to get the right values?

thank you very much!

Ps. I built the board my-self with an arduino nano, a few P-MOS and the RFM69HCW.

[kobuki]

For the EU band it's most likely wouldn't help. The transmitter frequency stability accurate TX timing seems more important as I remember my tests. Though testing doesn't hurt.

[ra1nb0w]

I changed the values and seems a bit better. We will see if this also fix the locking problem. I also did some testing with CC1101 transceiver but without luck. I also tried https://github.com/cmatteri/CC1101-Weather-Receiver but seems it doesn't work (at least in my case). Someone has did some experiment with that IC as TX? thank for the support!