Topic: Transmitting data to a Vantage Pro2 console with RFM69

[ct]

To get the correct temperature on console I need to set Byte4 | 0x08

Those 4 bits must mean something in the way the console calculates temperature.

[kobuki]

Thanks for the heads-up. Good to know!

[ct]

I think I managed to work the rain rate now, but I'm sure the information on dekay's wiki
https://github.com/dekay/DavisRFM69/wiki/Message-Protocol is not correct.

It says

light rain  if (Byte4 && 0x40) == 0
strong rain if (Byte4 && 0x40) == 0x40

but should be the other way round

strong rain  if (Byte4 && 0x40) == 0
light rain if (Byte4 && 0x40) == 0x40

[kobuki]

I remember collecting the rain rate information from multiple places. Maybe you could use my code in VPTools as basis for the conversion (see VP2P_RAINSECS in the case construct). What I built into the code seemed the most logical. However my code (based on the consensus of multiple information sources) doesn't reflect your findings about the strong rain flag. How did you test it?

BTW, are you planning to publish your code in some form in the future?

[ct]

How did you test it?

By observing what the console displays based on the values I send it.

If I send Byte3=0x64, Byte4=0x20 it displays 18.8 mm/h
If I send Byte3=0x64, Byte4=0x60 it displays 1.2 mm/h

0x20 | 0x40 == 0
0x60 | 0x40 == 0x40

BTW, are you planning to publish your code in some form in the future?

Possibly, if I can develop something that others could make use of.  But at the moment things are going very slow. I had a few promising days where the console remained in sync, but I reset the microcontroller and haven't been able to get the console to sync in over 12 hours.  Only a few packets are received and always on a different frequency index than the one the transmitter is using.  Like there is some kind of overlap.

Once the console manages to sync, it seems fine after that.  But the initial time to establish the sync is a problem.

[kobuki]

Possibly, if I can develop something that others could make use of.  But at the moment things are going very slow. I had a few promising days where the console remained in sync, but I reset the microcontroller and haven't been able to get the console to sync in over 12 hours.  Only a few packets are received and always on a different frequency index than the one the transmitter is using.  Like there is some kind of overlap.

Once the console manages to sync, it seems fine after that.  But the initial time to establish the sync is a problem.

What band are you using? EU/US/AU? It might have to do something with resonator accuracy in the Moteino, although I'm not sure. I mean, the timing might be skewed a little and initial sync is off, but then the receiver in the console compensates. You also need to follow the packet type pattern, otherwise you don't get sync. Although I think you do follow that since you seem to have long streaks of successful reception. I'll need to look into this later. I think radio parameters are fine, something else must be the issue.

[rdsman]

To get the correct temperature on console I need to set Byte4 | 0x08

CT:

I watched the incoming raw data from the VUE ISS and it appears that the bit that you set
is in fact always set.  I did the following transmission test for the type 80 message (degrees F)
and the VUE console is dead on:

-15.5 = 0xF658
-20.0 = 0xF388
50.0 = 0x1F48
51.0 = 0x1FE8
55.5 = 0x22B8
74.2 = 0x2E68
110.0 = 0x44C8
115.5 = 0x4838
120.8 = 0x4B88

As shown above, bytes 3 and 4 are combined.  In short the formula is desired temp * 160 | 0x08.

Good find!

[ct]

What band are you using? EU/US/AU?

US

[ct]

It might have to do something with resonator accuracy in the Moteino, although I'm not sure.

I'm not using a Moteino, if that is important, but an ATmega328p @8MHz/3.3v with an external crystal on a breadboard.   I have another transmitter on a Seeeduino Stalker board, which also is an ATmega328p @8MHz/3.3v with a crystal.  Same results with both.

[kobuki]

I'm not using a Moteino, if that is important, but an ATmega328p @8MHz/3.3v with an external crystal on a breadboard.   I have another transmitter on a Seeeduino Stalker board, which also is an ATmega328p @8MHz/3.3v with a crystal.  Same results with both.

Hmm. It could be frequency, then. Would it be possible to record a log of received packets from your station(s), containing all data and FEI, too, and post/pm me the log? The FEI values are accessible in my DavisRFM69 lib and in the queued packet data, too. There might be a large initial difference in the transmitted frequency, making it hard to sync initially. In the EU frequency table I see a small, but consistent difference for each individual frequency. It might be caused by the fact that the console is adapting the reception frequencies a little in addition to the receiver chip's AFC mechanism and these shifted frequencies were sniffed and then stored as the freq. hopping table.

The Moteino bit is only important because of the worse accuracy of the resonators used in them in comparison to xtal-based modules. But that in itself might not account to anything. On my Moteino receivers it never posed a problem.

[ct]

Hmm. It could be frequency, then. Would it be possible to record a log of received packets from your station(s), containing all data and FEI, too, and post/pm me the log?

Attached file is from ISSRx running for an hour.  However it has only managed to see 9 packets during that time.  The console has been succesfully receiving data during the same period.

[kobuki]

Hm, that's strange. I'm using this code to receive from 2 stations for months without a hitch. The 2 problems must be connected.

Could you try an older version? One before the bandwidth parameter tuning, like: https://github.com/kobuki/VPTools/tree/f13ab5e11f02d7715f92156d70d30ebe7ba88d0a

It might behave differently with the US band. Or your RFM69 module is faulty.

EDIT: oh, and this log is from an attempt to receive your own transmitter, or an original Davis one?

[ct]

EDIT: oh, and this log is from an attempt to receive your own transmitter, or an original Davis one?

The log is from an attempt to receive my own RFM69 transmitter.

Using an older version of library on both transmitter and ISRRx managed to sync, but with around 50% packet loss.  Console has also synced and receiving 100% of packets so far.

I've used both RFM69 modules successfully in recent days as transmitters, so don't suspect they are faulty.

[kobuki]

OK, I'm out of ideas for the moment. I haven't experienced any of the faults you're describing. It might have to do something with the US freq. sequence. The fact that the console is syncing 100% is promising but I can't point out on obvious fault with the transmitter from this. I'd need to experiment with the US band but it's illegal here in Europe everywhere unless I'm sitting in a Faraday cage

One last thing to try is to minimise serial printouts. Print only the most necessary things, like successful/failed packet count. The idea behind this is that the serial routines and interrupts might interfere with the transmission/reception timing.

[kobuki]

I've just committed a new revision on GH. Now it defaults to the old 25 kHz RXBW value since I've found the 50 kHz value to be a little flaky for one of my transmitters. Strangely enough, earlier the larger BW resulted in a better reception ratio for this same transmitter. Now it's easier to switch between the 2 for testing and might be useful for receiving stations flagged as console retransmitters.

OTOH, I see rather large FEI values on the few log lines you posted earlier. There are as large differences as 35 kHz! This might not sound bad at first but considering the bandwidth is a comparable value, it's actually a lot. While the AFC can probably handle it fine, it might still account for the flaky reception you experience. I think I'll implement the RX frequency adjustment, based on the FEI.

[ct]

With the changed settings to REG_RXBW and REG_AFCBW this is the log I get from ISSRx.  Synced at packet 34, then received around 50% of packets.

[kobuki]

Something's very odd with your logs. It starts with RSSI values at around -90..-100, and then suddenly increases to around -35..-40 (starting at packets:34/725/4.48). At the same time, dropped packets start to diminish to a normal level. If we don't consider the packets before this, your reception ratio is pretty good, at around 94%. Also, there are lines with delta:6204 (packets ~6 ms after the previous one), meaning there is another transmiter with ID 1 nearby. I think your RFM69 receiver is receiving 2 different stations on ID 1. Please set your ID to a different value (like 3 or 4, one less in code) and try again. It's not a very good idea to experiment using defaults.

The code currently doesn't guard against multiple transmitters with the same ID because because it will confuse reception anyway. Although I might implement a time-based guard later, it's useful sometimes and protects against RF noise as well, to some extent.

[ct]

At the same time, dropped packets start to diminish to a normal level. If we don't consider the packets before this, your reception ratio is pretty good, at around 94%.

The reception ratio seems around 50% to me.

I've changed TX_ID to 3 and the log looks similar.  When RSSI about -90 channel number is way off between transmitter and receiver.  When RSSI around -35 both are in sync but receiving around 50% of packets.  One line with delta:6312.

[kobuki]

The reception ratio seems around 50% to me.

Right. I made a mistake with the calculation. It's around 50% or so. Not good.

I've changed TX_ID to 3 and the log looks similar.  When RSSI about -90 channel number is way off between transmitter and receiver.  When RSSI around -35 both are in sync but receiving around 50% of packets.  One line with delta:6312.

Something's seriously off. You have set numStations to 1 and the stations array contains a single entry, right? Otherwise it's trying to sync to a second "phantom" transmitter and it might be successful at it (receiving bogus packets from your only station) sometimes, only to get confused and screw up the packet scheduler. This could explain the ~50% rate, too.

[ct]

Something's seriously off. You have set numStations to 1 and the stations array contains a single entry, right?

Yes


#define NUM_STATIONS 1

Station stations[NUM_STATIONS] = {
  { 3, STYPE_ISS,         true },
};


All the received packets match the data I am sending.  I don't see how another transmitter could be involved.

[kobuki]

OK. I still can't get why you have those short deltas, and why your 50% of packets get dropped. Makes no sense. Anyway, I can't test it using the US frequencies. Maybe later I'll set my console to the US band and test shortly with my transmitter. I don't have more ideas at the moment.

[kobuki]

@ct: to see more debuggingf info, coud you run another test with the following changes, please?

At line 101, please replace this:

Code: [Select]

  // fifo.queue((byte*)radio.DATA, radio.CHANNEL, -radio.RSSI, radio.FEI, lastRx - stations[curStation].lastRx);

with this:

Code: [Select]

  radio.DATA[8] = 0x55;
  fifo.queue((byte*)radio.DATA, radio.CHANNEL, -radio.RSSI, radio.FEI, lastRx - stations[curStation].lastRx);

and please post the logs. It will contain some garbage, but I might find out what happens. I have some ideas at least.

EDIT: now that I could take some time to look at the code a little, I'm starting to remember an important bit. I always had a hard time getting my Moteino receiver to sync with my transmitter. More precisely, had a hard time syncing them when I used the TX code modified for the Davis receiver/console. So now it's more like Davis or RFM69 on the RX side, but not both... Additional transmitters are most useful as cheap replacements for the factory ones. And they seem to work as one just fine. That doesn't mean I don't want to make it work like you're using it now (RFM69 to RFM69). But it will be hard. If you're willig to cooperate some more (mostly with logs, I think), I think we'll find a solution.

[ct]

Log attached

[ct]

That doesn't mean I don't want to make it work like you're using it now (RFM69 to RFM69). But it will be hard. If you're willig to cooperate some more (mostly with logs, I think), I think we'll find a solution.

I've only setup RFM69 to RFM69 in an attempt to verify the transmitter it sending anything.  My main goal is to have an RFM69 send to a console, which seems to be working when/if the console manages to sync.

I am happy to cooperate by providing logs etc if you want to get RFM69 - RFM69 working,  and appreciate the effort you are putting into this.

[kobuki]

Thanks. I've modified the transmitter code. I'm not committing it, since it might not work at all. Please test reception with the RFM69 and the console, too, if possible. See attachments with modified files.