Topic: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions

[ct]

I guess that's why everyone is using a BMP085

If building a new receiver, it may be worth checking out the BME280.  This sensor does pressure, temperature and humidity.

[blacklistedcard]

I guess that's why everyone is using a BMP085

If building a new receiver, it may be worth checking out the BME280.  This sensor does pressure, temperature and humidity.

I have a bmp180 sensor already from spark fun. I hooked it up and now have it feeding weather underground. I'm using Dekay git software and it's working great.   The Weather Underground wunder station is a nice console replacement.  I just have to work on the rain data now.

Using an IPad beside my nest thermostat on the wall.  Running the power cable through the wall to the electrical box

My original Davis console is dedicated to my Kenwood D710 and APRS. So I needed another console to feed the Weather Underground.

[kobuki]

The Weather Underground wunder station is a nice console replacement.

Too bad they don't have it for Android. It could have been a nice and cheap console replacement, using a cheapo 5-7" tablet...

[blacklistedcard]

Yeah....  It would be nice if they had it for Android.  All those surplus computer shops with those tablets for dirt cheap. Plus you could hookup the receiver module by usb to the tablet.  Then send it to Weather Underground by tablet.

[DeKay]

I guess that's why everyone is using a BMP085

If building a new receiver, it may be worth checking out the BME280.  This sensor does pressure, temperature and humidity.

Interesting.  Hadn't heard of the BME280 before.  You can get it on a breakout board from AliExpress for $8.54.  Specs on its temperature accuracy aren't very good though, so you end up with a two part solution again if you want decent performance.

[blacklistedcard]

I like the sht25.....  I don't see anyone throwing one of those into their Davis station though.  I notice that there will be an update to the SHT3x line in Q4 2015.

[CW2274]

I like the sht25.....  I don't see anyone throwing one of those into their Davis station though.  I notice that there will be an update to the SHT3x line in Q4 2015.

What's that have to do with the price of tea in China?

[blacklistedcard]

Using Dekay's awesome library that decodes the wireless Davis data from the ISS, I've got my project working where a Moteino receives the wireless weather data then sends it up to Weather Underground's PWS.  No Davis console or PC needed!  I put everything on Github.  I've wanted to do this for a long time and I really appreciate the tons of hard work DeKay put into reverse engineering the Davis communication.

Scott, I'm using some of your code for the weather underground data transfer.   Using the SIM900 GSM module, Moteino USB/RFM69HW; running off battery/solar.  So far I have the GSM module with the Moteino working off battery and solar just fine.  Working on getting yours and Dekay code mixed together transferring data from the sensors to weather underground.

I still have to figure what's wrong with my UV and solar sensor readings.  I used the example(s) but it does not match up with the real Davis console.

Thanks to everyone on this thread.   I have my project going.    I'll be happy when I finally get a enclosure with the solar panel.    Why is it so hard to find a nice outside enclosure with a solar panel of 5volts @ 2Amps.   I like the design of the Daivs Solar enclosures.

[blacklistedcard]

I like the sht25.....  I don't see anyone throwing one of those into their Davis station though.  I notice that there will be an update to the SHT3x line in Q4 2015.

What's that have to do with the price of tea in China?

You have a point... 

[kobuki]

blacklistedcard: sorry, but I just LOL'd seeing your nick

[kobuki]

A heads-up for those who have used my Arduino library. I finally had some time to tend to this project. I've modified the code a little. I'm accounting for the repeater bytes in the receive buffer and added 2 more "carrier start bytes" at the beginning of the packet for transmissions. I've just set my Envoy to receive a secondary temp. sensor at station 3 and I can see it picking up packets steadily, both in my WeeWX raw data collector database and when I check by using the STRMON command directly on the serial console. I'll leave it running a few hours and report back. Unfortunately I can't use the RFM69 chip to transmit using its automatic packet assembly mode, I still need to send all packet components as data bytes (preamble, sync word, etc), but it seems to be stable so far.

Edit 1: I almost forgot that I fixed the CRC calculation for TX mode. This bug effectively disabled sending...

[blacklistedcard]

Almost there.   I'm getting different data for the UV sensor than the console.  The UV on the console this second is 1.3, I'm getting 0.1.

case VP2P_UV:
    if ( radio.DATA[3] != SENSOR_OFFLINE )
    {
      tt = ((radio.DATA[3] << 8 | radio.DATA[4]) >> 6) - 1;
      loopData.uV = (float)(tt / 50.0);
    }
    else
    { loopData.uV = 0.0; }

#if 1
    Serial.print(F("UV: "));
    Serial.println(loopData.uV);
#endif

I got a solar battery to power the Moteino and sim900 shield (http://www.voltaicsystems.com/9-watt-kit).   It's been running non-stop for 4 days.  No http get commands to really juice the battery, so that will be the next test.

Hopefully in the next couple of weeks I'll get into an outside enclosure and have it running off the solar battery and sim900 to weather underground.  Completely self-contained and piping the data to weather underground by cell.

Thanks everyone...

[kobuki]

      tt = ((radio.DATA[3] << 8 | radio.DATA[4]) >> 6) - 1;
      loopData.uV = (float)(tt / 50.0);

I think I've made a mistake here. Could you please try without that -1 at the end? I'll revise this formula and fix it ASAP in the repo.

Other than this, everything else is spot on? Some values are averaged in the console over some minutes, IIRC, so not everything will be a 1:1 match.

EDIT: no, that -1 won't cause an error of this order of magnitude. That is a correction I found somewhere I can't find the reference for at the moment. That 1 divided by 50.0 at the end accounts only for a 0.02 of difference.

[blacklistedcard]

I'm thinking there is a problem with the sensor(brand new).   It's night here and the UV is at 3.  lol.

http://www.wunderground.com/personal-weather-station/dashboard?ID=IONTARIO1050#history

[kobuki]

Perfect. I suggest you put on sunglasses and tanning lotion

[docbee]

A heads-up for those who have used my Arduino library. I finally had some time to tend to this project. I've modified the code a little. I'm accounting for the repeater bytes in the receive buffer and added 2 more "carrier start bytes" at the beginning of the packet for transmissions. I've just set my Envoy to receive a secondary temp. sensor at station 3 and I can see it picking up packets steadily, both in my WeeWX raw data collector database and when I check by using the STRMON command directly on the serial console. I'll leave it running a few hours and report back. Unfortunately I can't use the RFM69 chip to transmit using its automatic packet assembly mode, I still need to send all packet components as data bytes (preamble, sync word, etc), but it seems to be stable so far.

Edit 1: I almost forgot that I fixed the CRC calculation for TX mode. This bug effectively disabled sending...

Applying the more relaxed bandwidth settings does improve reception of retransmitted packets for me as well. It also helps to dim down the original sensor data by reduction of RF threshold level.

[kobuki]

@docbee: to amend your post, the new change in the lib is very recent, it was not included in the change set when I wrote the previous notice.

I don't exactly get what you mean by "It also helps to dim down the original sensor data by reduction of RF threshold level" - would you elaborate on it a bit more, please? I haven't experienced worse reception, in fact, it made reception a bit more stable (packet reception ratio has increased) even for existing standard transmitters.

[docbee]

I did 2 things to improve console retransmit reception.
1) changing REG_RXBW and REG_AFCBW to RF_RXBW_EXP_2
2) cutting off general RF noise by setting REG_RSSITHRESH to 100 (equal -50db)

Both changes have side effects but without these the reception of retransmit packets is not really good (lots of blank phases).

BTW: I have tested on a European Vantage version.

[kobuki]

Oh, I see. The fact that raising the RSSI threshold can diminish a lot of noise is well known, even DeKay noted it more than once. Widening reception range is something new I tried after writing my new OOK library for the RFM69, where it also plays an important role.

My recent changes in vptools allow simple reading of FEI, it would be interesting to know how much the frequencies are off in case of the retransmitting console.

[mcrossley]

I've not seen anything in my searches, but has anyone decoded packet type 0xC?

From my ISS ("old" firmware) is see the well documented packet sequence...

Code: [Select]

8 E 5 4
8 E 5 9
8 E 5 A
8 E 5 A
8 E 5 6
But from my anemometer transmitter ("newer" firmware, but still years old)  I am seeing the sequence...

Code: [Select]

8 E 5 4
8 E 5 9
8 E 5 C
8 E 5 A
8 E 5 6
Example packets...

Code: [Select]

C0-01-A4-00-03-00-61-B5-FF-FF
C0-01-A7-00-01-00-9C-0B-FF-FF
C0-03-A7-00-03-00-BE-EA-FF-FF
C0-00-A7-00-03-00-50-38-FF-FF
C0-00-A5-00-03-00-BD-50-FF-FF
C0-00-A9-00-01-00-94-00-FF-FF


[kobuki]

Nothing is known avout packet type 0xC at the moment. It can be transmitted from T/H and standalone anemometer transmitters, and might has some relation to their nature, ie. only one specific sensor is attached. I can also see them in my packed dumps for my anemometer transmitter, though I attached the solar/UV sensors there as well. Maybe newer firmware sends it as some additional info. I think it's safe to use the old sequence for your relay.

[mcrossley]

Thanks, I'm trying to get the reception better before I move on to transmission. Picking both stations can take a long time, and though it works pretty reliably once it is locked on to both transmitters, the packet drop rate is still much higher than my consoles (success = 80's% v. 90's%).

[kobuki]

20% packet loss is a little excessive. Try to align the wire antenna perpendicular to the board, or attach a decent rubber ducky dipole. With 3 transmitters I used to receive above 95% and with the 2 constantly running transmitters it's around 97% all the time. EU frequencies but after lock-on it shouldn't make a difference.

[mcrossley]

OK, I finally have my relay code working reliably. I thought I had it working last week, but I found a difference in reception requirements between the console firmware versions I am running.

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. Once I implemented this both consoles will now lock on to the first packet they see - result! - and I get all but 100% reception stats, the odd dropped packets are probably 3G phone interference as I'm sharing a band with them (sshhh!  ).

So to sum up I'm receiving data from a Davis ISS transmitter (2) and anemometer (1) and rebroadcasting as a single ISS (3). This allows me to move my solar and UV from the 'real' ISS to the anemometer.

My little Moteino project is based on a fork of Kobuki's excellent VPtools  to which I have made a few tweaks.

• Added the ability to adjust the packet timer - the Moteinos were running faster than the observed Davis intervals. Despite being a small correction this made quite a bit impact to the reception stats on my 'backup' console.
• Added the ability to adjust the RFM69 frequencies. My two Moteinos were broadcasting approximately 22 & 28 kHz higher than the Davis devices
• Added the option to flash the Moteino LED on receive and/or transmit
• Made the first detection of a transmitter much more robust, the Moteino now locks on after seeing the first packet

My fork of VPtools is here - I'll make a pull request back to Kobuki if he wishes to incorporate the changes.

[kobuki]

Nice work! I'd definitely like to add changes aiming robustness or tunings necessary for certain board samples (eg. to adjust Moteino frequency skew). But I think I'll first have to look deeper into the changes we haven't discussed yet. It would be nice to have a single library supporting all basic cases of operation, including a relay such as yours.

• Made the first detection of a transmitter much more robust, the Moteino now locks on after seeing the first packet

What does this change exactly do to make it more robust? In my tests it almost always locked on the first packet on the current probe channel.