Topic: Transmitting data to a Vantage Pro2 console with RFM69

[Craig12345]

Yes, and that is the beauty of these forums: it becomes a collaboration among high-flyers and the rest of us can watch the conversations.  Like a school study group where two of the group are wizzards, everybody else benefits from the discussion and the excitement.  Even the wizzards learn more from answering questions from the rest.  It is a thing of educational beauty! 

[kobuki]

My contribution to this thread is to refer the reader to a later (12/25/2019) foundational comment, for US users, by Kobuki on another thread: https://www.wxforum.net/index.php?topic=10739.msg369114#msg369114.  After spending weeks working with two Moteinos and the ISSRx and AnememoterTX VPTools code, I have had spurious and limitted success.  But in the best case my packet reception by the RX_Moteino was about 50% recieving about every other packet as described by the referenced Kobuki post.  The VP2 never got one hit according to the Reception Diagnostic screen.  My aim was to transmit WX data derived from the web to my orphaned VP2 console.  The ISS was lost/destroyed and I don't want to spend the $$$ to replace it.

So, I think I'm at the end of this rope.  I thank Kobuki, DeKay, ck, mcrossley and others for digging deep into the weeds on this!

The AnemometerTX sketch is just a POC, not meant for real life scenarios, it's clearly stated in the readme. Its not optimized for battery operation and the timing is not by interrupts but busy-wait loops. The solution has issues with US band reception but since I don't have a US transmitter, I havent yet been able to fix it. In its current state it's able to receive 100% of the packets, but only after fine-tuning timing and frequencies which defeats the purpose of an easy to use library.

[kobuki]

I'd like to use the library, but unfortunately it is too complex at this time and seems more of a proof of concept rather than a real library - it does not lend itself as a wrapper like most libraries do such as calls like xmtTemp('48.5'), or such. It requires very in-depth knowledge to even start working.

I'm not sure what you're referring to and what your ideas are of a "real library" or "too complex". It does what it needs to. If you look at the examples, you need to change maybe 3 or 4 lines to make it receive your stations and have it log the interpreted data on the serial line. The lib is being used in literally hundreds of devices I alone know of, without any issues.

But anyway, the repo itself is meant to serve as a basis for enthusiasts like myself and is specifically for receiving or transmitting packets suitable for a single type of device (Davis VP2 and alike). If you don't know what you're doing, you're out of luck. In the context of these devices, a single statement transmitting a single temperature value is absolutely meaningless. Please do your homework before coming here saying this nonsense. If you do, I'm willing to help.

[Craig12345]

Kobuki, Thanks for the responses.  I've got some spousal assignments before I can get back to this.  I have some questions to proceed, but not before I do more work myself (reread the chain and retry the programs).  I'm close... oh so close...   

[Craig12345]

I reread the blog chain (3rd time) to make sure I didn’t ask a redundant question.  Great stuff.  Much like the blogger named ct, my objective is to use your code to send data to a VP2 console via a Moteino/ESP8266 combo.  I’m hoping to snag data from any nearby WU site or alternatively from a weather buoy off the coast of Oregon.  At the moment I’m testing Moteino to Moteino (RFM69HCW’s) sending fake data (Data[3:5] as zeros).
 
So far I’ve:
1.   Confirmed the Moteino’s work together using Felix’s demo code(Gateway/Node).
2.   Am now able to get about 50% reception with your ISSRx program and with occasional runs of 5, or so, consecutive successes.  Timing looks good on the consecutive successes (2.56 s).  I had to move the TX Moteino to another room to drop the RSSI to about -48.  If RX & TX are in the same room I’m getting RSSI of < -10  and RX reception of about 15%.   The packets making it through are identical to the TX serial output so I know it works.
3.   Failed to ever get my orphaned VP2 to see anything.  Though I can pick-up a neighbors ISS; I don’t want to depend on it.

I have the following questions, if you would be so kind:
1.   

“In its current state it's able to receive 100% of the packets, but only after fine-tuning timing and frequencies which defeats the purpose of an easy to use library.”

Any hints at how I can tune the timing and frequencies? 
2.   The AnemometerTX code has a variable TX_ID.  The ISSRx appears to not have an equivalent station identifier and will accept any transmission.  Is that right? 
3.   A related question, In the current ISSRx “stations” refers to the array established just lines above as “Station stations[3]…”, right?  I tried to trace where the code goes in “radio.setStations(stations, 2); was going but I got lost fast.  The code has evolved but note Reply #68  left me knowing that I don’t understand what “stations” means.  It must not mean the same as it does on the VP2 console.

Thanks again for your work on this.  It is over my head, but I’m hoping that I can make a go of it.

[kobuki]

2.   Am now able to get about 50% reception with your ISSRx program and with occasional runs of 5, or so, consecutive successes.  Timing looks good on the consecutive successes (2.56 s).  I had to move the TX Moteino to another room to drop the RSSI to about -48.  If RX & TX are in the same room I’m getting RSSI of < -10  and RX reception of about 15%.   The packets making it through are identical to the TX serial output so I know it works.

You could try lowering the output power. When the signal is too strong it can cause distortion and worse actual reception. But if moving the transmitter away isn't very inconvenient, you could just leave it at that.

3.   Failed to ever get my orphaned VP2 to see anything.  Though I can pick-up a neighbors ISS; I don’t want to depend on it.

You mean a VP2 console? It should sync on the Moteino just like another Moteino. Needs more tests, works fine on the the EU band. I admit, transmit functionality does work but also needs freq. tuning.

1.   

“In its current state it's able to receive 100% of the packets, but only after fine-tuning timing and frequencies which defeats the purpose of an easy to use library.”

Any hints at how I can tune the timing and frequencies? 

The best way to go is probably using an SDR stick and noting/implementing the actual frequencies where the packets appear. That's an effective strategy that worked for others. The timing is lenient enough to allow for errors, I think you don't need to touch that. I'll get a US transmitter sometime in the future to fix this up. I have a pure SW idea for fixing that using the RFM69 FEI value but I'd also be doing that blind...

2.   The AnemometerTX code has a variable TX_ID.  The ISSRx appears to not have an equivalent station identifier and will accept any transmission.  Is that right?

3.   A related question, In the current ISSRx “stations” refers to the array established just lines above as “Station stations[3]…”, right?  I tried to trace where the code goes in “radio.setStations(stations, 2); was going but I got lost fast.  The code has evolved but note Reply #68  left me knowing that I don’t understand what “stations” means.  It must not mean the same as it does on the VP2 console.

ISSRx and similar sketches using the lib employ a station array (named stations), where you can define the station ID (one less than the one set on a SIM board using the switches) and the station type, active flag (listen to it or ignore it). ISSRx.ino has a sample for 3 stations predefined and you can have a max of 8 entries. If you transmit using e.g. TX_ID=5 (Davis notation: station no. 6), then you need a stations array member with ID == 5 to capture that data. From memory, setStations() 2nd parameter sets the number of stations to be picked up from the passed array.

I hope I was able to answer everything but just ask if I wasn't.

[safuser]

I have been running modified MCrossley RxTx code on a Adafruit Feather ESP32 with RFM69HCW module.  Accepting data on ID1 and re-transmitting on ID4 to VP2 Console.  I had to tweak the frequency offset of the RFM69 module a bit, but it has been working great for about a year now(on US Freqs).  It also connects to my wifi via the second thread on the ESP32.  Initial capability to store persistent station data on the Feather EEPROM( i.e. total yearly rainfall, high/low wind gusts, wifi settings etc.).  I modified it to use internal timers on ESP32 for lack of MsTimer2 support.  It has the startings of Davis VP2 Loop Support and easyweather out support.  It has an internal stationdata structure to store Wx data to send to VP2 Console or over wifi.  Intent was to be able to read from other sensors via I2C (i.e. SHT85, BMP388, etc).  It could be easily modified to use other Anemometer or sensors.  Has featherwing OLED support for display.  Definitely a work in progress as I have not had much time lately to finish.   You are more than welcome to take a look at the code.

[Craig12345]

Most exciting!  I have new hope.  Thanks both kobuki and safuser!
@kobuki:  I will next implement your suggestions (disable setHighPower(), purchase an SDR and learn how it works, and take a few liberties with the station array per the below notes.)  The SDR may take me a week to two to obtain.  Andreas Spiess has a series on SDR radios.  In the mean-time I propose making the following edits to your station array.  I'm trying to use STATION 2 on the console and it is the ISS that I am trying to emulate on the ISSRx Moteino.

1.  ISSRx.ino changes:
Station stations[3] = {
  { 0, STYPE_TEMP_ONLY,   false },       // moved from original position to maintain 0:2 ordinal sequence; false = I don't need it.
  { 1, STYPE_ISS,         true },            // 1 here equals 2 on VP2 console
  { 2, STYPE_WLESS_ANEMO, false },  // false = I don't need it.
};
Then, just below in void setup()
  radio.setStations(stations, 1);            //changed from default of 2 to 1 thinking that 1 = STYPE_ISS from the array above.
                                                         // but I know that 1 = numStations from .ccp file.  I'm only using one station, right? 
2.  AnemometerTX.ino changes:
#define TX_ID 1

VP2 Console changes:
STATION 2

To answer your question: Yes, VP2 in my espression means console.  These above changes have compiled & uploaded.  But something is wrong; I'm getting no data transfers (moteino-moteino, or moteino-VP2_console). 

I'll follow-up after I get & learn the SDR side.  Does this mean that SDR results could drive changes to some members of the 3X51 FRF_US table?   I wish I had a spare ISS_US that I could send you!  Well, that and a faraday cage to keep it legal. 

[Craig12345]

@safuser - Thanks.  I very much want to look at your code.  I was aware of the MCrossley work, but am trying to focus on the kobuki/DeKay builds.  I googled for your code and couldn't find it.  But I did find some links to you on other Wxforum entries that are right up this alley.  Perfect, more to learn.  If I could see your code I'd be looking for your frequency offset.  That sounds simple enough, right? 
When I bough the Motino's I went for the added flash memory for storage of variables.  My original thinking was to limit the ESP to simple TX/RX of the variables.  But I'm new here and own a pile of ESP8266 but no ESP32's.  I'll buy more if I need to.  I'll be buying an SDR radio anyway to look at the frequencies.  That brings me to another reason to look at your code: I'd like to see if your US freq table is identical to the one used by kobuki.  I know that there is no difference to the table used by DeKay, the originator, I think.  I look forward to hearing from you on a code link, or something.  Your jpg is a thing of beauty!

[safuser]

I used the serial command of the RxTx Code to adjust offest while the VP2 Console was in monitor mode and tweaked until I got the best results. i.e. the least correction by the VP2 console.  Th RxTx Code stores this correction in EEprom for the next time.  All my boards  are a little different.  PM me your email and I'll send. 

[kobuki]

In the mean-time I propose making the following edits to your station array.

It's just a sample, so just change the array to fit your needs. Be aware that the 2nd parameter truncates the array, keeping the head, so you'll need to put the needed elements at the beginning. It'd be better to close the array with a NULL instead of the size parameter, I might add an overloaded function sometime.

I'll follow-up after I get & learn the SDR side.  Does this mean that SDR results could drive changes to some members of the 3X51 FRF_US table?

Yeah, you'll need to change the freq. array. The frequencies need to be converted using a formula (a simple division), I'll look that up later if you don't find it. It's in the RFM69 datasheet, anyway.

EDIT: I suggest getting a low PPM stick, to avoid the hassles of regular calibration. 0.5-1PPM TXCO sticks can be had for several 10$.

I wish I had a spare ISS_US that I could send you!  Well, that and a faraday cage to keep it legal.

I wish I had one, too. I have a lot of Faraday cages, don't worry

[Craig12345]

@ kobuki:  Thanks again for your body of work on this and sorry to be so wooden-headed about this stuff.  I didn't understand the part about "2nd parameter truncates the array, keeping the head, so you'll need to put the needed elements at the beginning."  When you say "2nd parameter", do you mean the 2nd parameter of the statement  radio.setStations(stations, 1);?  I did change that in my proposed (and completed) change in my code and I changed the order of the array hoping that I was covered.  But nothing works so I am missing something. 

@ safuser:  I think I sent a PM with my email.  I tried multiple times.  I Hope it arrived safely.

Yes, failure abounds for me but I keep trying.   
   

[kobuki]

I have been running modified MCrossley RxTx code on a Adafruit Feather ESP32 with RFM69HCW module.
...

Nice image. Any chance of sharing the code somewhere?

[Craig12345]

@Kobuki – Happy to report that I got your AnemometerTX.ino working on a Moteino with a frequency correction!  Details are below.  Safuser helped me a bunch with this idea as did you with the SDR prospect.  His code, and the code of others, included the ability to adjust the TX timing and frequency during program execution by passing adjustment values via serial input from the IDE.  However, I seemed to be unable to get that feature to work.

My guess is that the Moteino radios have some small crystal timing differences that affect the frequency output.  I understand that the VP2 console has a 5ms RX timing window, wide enough to accommodate some timing differences.  But the granularity of the frequency must be more demanding.  Currently I’m sending dummy data.  My next step is to send CWOP/WU data from some select station(s). 

Details of my change:
In DavisRFM69.cpp, on line 47 I invoked the frequency correction directly by making this edit:
volatile int16_t DavisRFM69::freqCorr = -500;  //value used to be 0

I hope that this may be of use to others.  Thanks again to you, safuser, and all those who came before!

[kobuki]

Nice! I'm glad you were able to fix the freq. error. So it's a simple -500 offset?

In DavisRFM69.cpp, on line 47 I invoked the frequency correction directly by making this edit:
volatile int16_t DavisRFM69::freqCorr = -500;  //value used to be 0

You know, there's a DavisRFM69::setFreqCorr() function for that...

EDIT: to cause the same effect as the change you made, you need to call radio.setFreqCorr(-30) after initialization - this will set a value of -491, the closest possible with integers. This in effect means a general -30 kHz frequency offset. I'm a bit surprised that this can cause problems to such degree as to lose every other package. I might need to expand the AFC range or indeed implement automatic offset correction. You're right, the xtal on the module is not the best, but most of the time it's just fine. Apparently not so for Davis (or not for all bands - the EU band is fine as is).

[Craig12345]

@Kobuki:  Yes, -500.  I am still fine tuning the value while looking at the reception diagnostic screen of the VP2 console.  Values of -400, and -450 also work for me, just not as well.  I've seen others useing values in the range of -200 to -400.  I suspect each Moteino will need different values. 

You know, there's a DavisRFM69::setFreqCorr() function for that...

Yes, I found that earlier.  But being lazy and of very limited programming skill, I went straight to the bone.

[kobuki]

I've seen others useing values in the range of -200 to -400.

I'm curious where these other people are Transmitting seems like a niché use case. I'd like to share experience, but I don't have many contacts on the other freq. bands.

[Craig12345]

Hi Kobuki (love that name BTW – easy to remember.)
Given the name of this thread ... I would think that transmitting is the focus.  Lots of work by, I think, by Crossley, Scott216, safuser mixes both TX and RX functioning as a relay & station combining.  In those works, I was having a hard time determining if the frequency correction would affect the RX, the TX, or both... again, being of limited skill.  So that is what really thrilled me about the singular TX purpose of the AnemometerTX code.

[kobuki]

Hi Kobuki (love that name BTW – easy to remember.)
Given the name of this thread ... I would think that transmitting is the focus.  Lots of work by, I think, by Crossley, Scott216, safuser mixes both TX and RX functioning as a relay & station combining.  In those works, I was having a hard time determining if the frequency correction would affect the RX, the TX, or both... again, being of limited skill.  So that is what really thrilled me about the singular TX purpose of the AnemometerTX code.

The thread's not the world

Actually, the library does have the simultaneous transmit functionality, and I wanted to make something like Mark's RxTx sketch, but because of the flaky US band I halted working on that. I have test code that works on the EU band, tho. It largely does the same as RxTx, with less bling (logging is minimal) and without combining packets. You can activate transmitting via enableTx() and a callback you implement that provides the actual payload that you can just copy from a station or assemble/combine your own. I can push my test code if you want a peek. It might even work properly for you after your frequency adjustments.

[safuser]

Kobuki,  I don't really  have anywhere to share the code, but I can email it to you if you PM me your address?

[kobuki]

Kobuki,  I don't really  have anywhere to share the code, but I can email it to you if you PM me your address?

Sorry, not sure what code you want to send, but you can just attach it to a PM, I think. If that works.

[Craig12345]

Nice image. Any chance of sharing the code somewhere?

@Kobuki:  If you get a chance check out the safuser code.  One of the coolest features, outside of the RX/TX thing, is the ability for the serial input on the fly.  When I get the same gear as safuser photographed, I will run it.  I think Mark Crossley also has this in his RxTx code, but I could not get that serial feature to work on my Moteino.  Another cool feature is the tiny form factor of the board as photographed. 


@safuser: Thanks again for the code and the shopping list.