Author Topic: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions  (Read 63577 times)

0 Members and 1 Guest are viewing this topic.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #175 on: January 15, 2017, 09:17:12 AM »
AS I mentioned, I effectively just broke the combined && clauses in the if statement in your code into separate if's. I also added an extra check, but that is only a belt'n'braces as I am transmitting as well as receiving. I cannot see anything wrong with your logic or syntax.

I find with your original code, and with my extra clause it would often see the first packet on the channel it was listening to for new transmitters, but then fail to pick up the subsequent one. Often it would only 'lock on' to the first transmitter when it saw the first packet from the second transmitter - or it timed out and went into 'broadcast listening' mode again.

With the separated if clauses it picks up the a new transmitter and always get the channel 1, 2, 3 packets. I cannot explain why as the code logic is the same!

I have just found a problem with my relay code - one a error on my part, I was not resetting the bad battery status after it cleared, now fixed.

I had a weird packet from my anemometer last night...
Code: [Select]
C8-C0-00-00-A8-40-5C-D9-E5-C9Which the console interpreted as a wind speed of 194 mph direction 0. The VPtools decode said it was an unknown packet without valid wind data. This is what also triggered me to find the battery status bug.

Whats concerning is that the check sum apparently passed, and then I "lost" that transmitter for 80 seconds, then picked it up again without having to re-sync on it. So did the transmitter have a funny turn?

EDIT: Budder! My rain gauge reed switch has packed up today - anyone know what the replacement component is off the tops of their head?
« Last Edit: January 15, 2017, 09:19:52 AM by mcrossley »
Mark

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #176 on: January 15, 2017, 11:07:26 AM »
I see, thanks for the explanation. Sorry for yet another nitpicking, but you write: "It turns out that the later firmware requires an additional 0xff byte to be transmitted after the data." - it already sends 2 0xff bytes (repeater info placeholders), and I couldn't find anything in your code that adds more of them, did I miss something?

The reed tube is this one here. I used to see it on Ebay too but not any more. I'd probably measure the dimensions of the old failed one and try to buy something similar.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #177 on: January 15, 2017, 12:03:10 PM »
Hi, line 434 in DavisRFM69.cpp, I send DATA[9] a second time...
Code: [Select]
  // transmit dummy repeater info (always 0xff, 0xff for a normal packet without repeaters)
  DATA[8] = DATA[9] = 0xff;
  SPI.transfer(DATA[8]);
  SPI.transfer(DATA[9]);

  // extra 0xff byte required after message for console to sync reliably
  SPI.transfer(DATA[9]);

I had an idea, my old Fine offset was still in the back of my shed somewhere - dug it out and it has 9x NO reed switches in it (8 in the direction, one in the speed). Salvaged one of those and soldered into the Davis - and its working again.  \:D/ The leads have been clipped too short on the FO reeds, and they look really cheap switches but it will do for now as I'm away with work again tomorrow.
Mark

Offline Nyowe_Nkanye25

  • Member
  • *
  • Posts: 1
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #178 on: January 24, 2019, 10:02:19 AM »
Kindly share with me.
Thanks

Offline safuser

  • Member
  • *
  • Posts: 49
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #179 on: January 24, 2019, 12:31:12 PM »
mcrossley,  Is your current code available on github?  Would it be possible to get a copy if not.  I am currently having mixed results with the current github code on several moteinos and a VP2 console.

Thanks.
« Last Edit: January 24, 2019, 12:34:24 PM by safuser »

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #180 on: January 24, 2019, 12:38:31 PM »
I'm not sure it's current - but other people have successfully used it.
It is also way out of date with kobuki's master copy - I'd recommend you try his first.

I have about 4 copies knocking around my laptop all with uncommited changes, and to be honest I've forgotten which one is running on my Moteino!  ](*,)
Mark

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #181 on: January 25, 2019, 02:55:38 PM »
If you don't need mcrossley's relay functionality, you can use my driver, but only on EU frequencies. The US reception setting has a weird bug that makes the receiver skip every other packet on average, but since I don't have access to US transmitters, I can't fix it. Maybe if someone wants to sell a used SIM for cheap I can work on it again. On EU it works perfectly. The timing is the same so I have no idea why it's broken. Mcrossley does the timing a bit differently but the code is almost the same. The WxReceiver sketch and the weewx-meteoRX driver are a good woking combo in my repo that is used at a lot of places.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #182 on: October 06, 2020, 04:31:03 AM »
Thread resurrection!

But I had not seen this documented anywhere before - maybe I'm wrong?

The rain packet 0x0E data in byte 3 contains a flag in bit 8 for a counter reset.

When first powered on the ISS sends x80 in byte 3.
This then increments for each rain tip until it reaches xFF.
It then wraps to x00 and increments up for each tip to x7F where it wraps to 0x00 again.

So only the lower 7 bits are the counter, with bit 8 being set after a power reset of the ISS for the whole of the first counter cycle.

I'm surmising this is to tell the VP2 console to reset its own internal counter to match to the ISS counter the first time it receives a packet with bit 8 set and thus avoid a large spike in rainfall if the ISS is power cycled.
Mark

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #183 on: October 06, 2020, 05:04:34 AM »
Thanks for the heads-up. I'll also implement it in our WeeWx driver.

Offline snapper

  • Senior Member
  • **
  • Posts: 64
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #184 on: August 06, 2021, 03:14:34 PM »
Hi,

Has anyone managed to get the kobuki WxReceiver sketch working with 3 transmitters?
I have 3 separate transmitters for my Davis station (ch1=Wind/UV/Solar, ch2=TempHum, ch3=Rain), the sketch compiles and runs fine on my Moteino R4 with rubber antenna, however after a short while it starts dropping packets and eventually stops.Then I’m guessing there is a timeout and it starts working fine again, and degrades…
I know packets are being transmitted as I can see the wind changing on the VP2 console, but the motino doesn’t.
It’s the same even if I use the t command to only listen to less transmitters (i.e. t1, t3 & t7 all show the same behaviour)

I know the hardware is good as the mcrossley RelayRxTx sketch will run for hours in the same location, with only minimal packet loss.

Any ideas?

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #185 on: August 06, 2021, 03:18:38 PM »
This question belongs to the VPTools GitHub issue page. Please ask there and I'll try to answer your questions.

One quick note though: the US band is still problematic as I haven't got around fixing the timing skew on the US band (on the EU band, no problems with 3-4 or more transmitters). Matt's sketches require manual freq. calibration first to alleviate the issue.
« Last Edit: August 06, 2021, 03:21:31 PM by kobuki »

Offline snapper

  • Senior Member
  • **
  • Posts: 64
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #186 on: August 06, 2021, 03:27:51 PM »
Will do, thanks for the quick reply.

This is EU band as I’m UK.

 

anything