Davis VP2 Relay Device

[mcrossley]

You are supposed to solder the antenna wire to the board, but if you have a push fit it should be OK.

The "no soldering" was for making data/power connections.

The transmission ID is set here...

Code: Select all

#define TX_ID 2 // 0..7, Davis transmitter ID, set to a different value than all other transmitters
                // IMPORTANT: set it ONE LESS than you'd set it on the ISS via the DIP switch; 1 here is 2 on the ISS/Davis console


By default the code should be set to Station #3 (TX_ID=2).

[Herbaldew]

Bummer

I had my fingers crossed, but based on the quote below I knew it may not work for me given my different console firmware.

I will now keep my fingers crossed that someone whom is not clueless as I, with my firmware version, decides to give this a go and shares their results

Thanks anyway!

The code worked fine on my 'backup' console which is running ancient firmware - Nov 13 2004 - but when I tried to connect my 'production' console (v3.12) it failed to lock on the transmissions (well it did one time I tried then I couldn't repeat it). It turns out that the later firmware requires an additional 0xff byte to be transmitted after the data.

[mcrossley]

It should work - it works fine with my console running ver 3.12 - and I think the author of VP tools has checked the code out and got it working.

Do you get any sort of lock at all?

I used a SDR dongle to check it was actually transmitting - and used that plus the reception stats to 'tune' the frequency offset in the code. Maybe your frequency is a bit off too? If you look in DavisRFM69.h then this defines the offset...

Code: Select all

#define FREQ_CORR 0         // Frequency correction factor for RFM69 = (Required correction Hz) / 61
                            // E.g. 20kHz = 20000/61 = 328, should use RF_FSTEP, but 61 is close enough
                            // My Moteino's #1 = -450, #2 = -340


As you can see my two Moteinos needed that setting to -450 and -340, maybe take a punt and try setting it to -400 and see what happens? You can set it dynamically over the serial port with the command "q-400"

[Herbaldew]

Bingo ! !

On first try, part of the data was showing and the Rx indicator on the console (X) was frozen and on. Try two and all is well

I don't have any gizmos to help me tune it but will just keep putting in different offsets and watch the reception rate to zero in on what number works best.

Thanks again!



I remember reading somewhere that you said to turn off the serial monitoring (and maybe other things) due to its CPU use but can't find it at the moment. I think I see where this is but not sure how to disable it ... for the sake of consolidating the info on how to do that, would you mind adding it to this thread?

[mcrossley]

I thought the serial commands are in the Readme file - but it looks like I didn't update it with the latest features!

Code: Select all

....
The sketch implements a number of serial commands to configure some aspects of behaviour:

  tn.nnnnn
    (where 1.2 < n.nn > 0.8) - Sets the timer adjustment factor to compenstate for clock differences

  on
    (where n = 0, 1, 2, 3) - Switches serial data output
    0 = off
    1 = full stats + data
    2 = full data only
    3 = wind data only (speed,direction)

  fnnnnnnnn
    (where each n = 0 or 1) - Switches output from a particular transmitter id 1-8 off or on
    You can send only the ids up to last one you want to set, eg: only turn transmitter 3 off = f110

  qnnnnn
    (where -1000 < nnn < 1000) - Sets the RFM69 frequency offset

  r
    Shows the current radio stats for each transmitter id

  ?
    Shows the current configuration values

The configuration values are stored to EEPROM so will survive a power cycle.


So to switch serial output off the command would be "o0" (oh-zero)

[mcrossley]

The console radio screen has a field which shows the frequency correction applied to lock on to the transmitter - adjust the correction to get that bouncing around zero. (mine is normally between +/- 1) Without the frequency adjustment it was up in the 20's.

[Herbaldew]

The console radio screen has a field which shows the frequency correction applied to lock on to the transmitter - adjust the correction to get that bouncing around zero. (mine is normally between +/- 1) Without the frequency adjustment it was up in the 20's.

Cool. I changed the freq correction from -400 to -340 to start my testing and got side tracked and never tried anything else.

Just checked with this method and it is spot on!

[Herbaldew]

A note to others whom may give this a go....

Although I did get reception after entering the freq correction, I could only get around 10 feet range and was getting around 80% packet reception.

I guess it is from watching too many episodes of "Tool Time" years ago, but I just had to order the high power Moteino.

If I had read the description of the Moteino I ordered properly, I would have picked up on this (the 'important note' part was even highlighted ):

IMPORTANT NOTE: ..... The RFM69Hxx radios (H = high power, 20dBm) require the setHighPower() function call after initialize.

So after adding:

Code: Select all

#define IS_RFM69HW_HCW

radio.setHighPower();

all is well.

The device ran all night transmitting from behind my home theater electronics 30 feet through two walls with 100% packet reception

[mcrossley]

Great! This is the first report of someone actually running a relay apart from me.

Have you tried moving the solar sensor to the wind transmitter yet?

[Herbaldew]

Have you tried moving the solar sensor to the wind transmitter yet?

Just finished up.

I had my mount all thought out and the materials on hand. I removed the sensors from the ISS and went up on the roof to plug them in for a test. They sat so well on top of the transmitter housing that I came back down and grabbed two cable ties and a piece of plastic to use as a leveling spacer and and job is done. Well, I did have to adjust the leveling screws on the sensors a tad.

Along with getting better readings, I consider this a security measure. If my ISS grows legs, now it can't carry those expensive sensors off with it!

Thanks again!

[Herbaldew]

I thought about snow and ice this winter and decided to scrap the cable tie method and go ahead with my original plans to make a proper mount out of aluminum square tube and a stainless U bolt from my old VP system.

[mcrossley]

Looks like a good job - only one question are they far enough in front of the mast so they aren't shadowed at midsummer?

At my latitude the Sun rises/sets at midsummer approximately 45 degrees either side of North.

[Herbaldew]

I don't know - I haven't noticed that happening but we haven't had a totally clear day since I moved them. I am 15 degs farther south than you. I have another piece of aluminum that I could have used to extend them out further but would have taken more work. I will use it if it becomes necessary.

I also thought of shooting the mast with some flat black paint above the sensors to cut down on reflection beings my mast is so shiny.

Oh, and the chimney is inactive

[Herbaldew]

Oops! I had a max wind of 253 MPH today.

I see you had a similar happening in January - everything cool since then?

[mcrossley]

Yep, I've not had a repeat of that since. Keep me posted though, to have hit a problem so soon is a bit worrying.

I'm not 100% convinced that we *fully* understand the data encoding though. There a a couple of bits that I think are set just "because they work", not because their function is understood. I have noticed that on one occasion the console flagged the wind sensor as disconnected for one packet every minute-ish. I never got to the bottom of it as I wasn't logging the diags at the time, but I think it was a combination of either a solar or UV packet with a specific value and the wind data not behaving correctly. I've never seen it again, but then I don't sit staring at the console continuously either!