Skip to content
This repository has been archived by the owner. It is now read-only.

Davis Vantage Vue ISS? #3

Closed
mzac opened this Issue Feb 13, 2016 · 24 comments

Comments

Projects
None yet
5 participants
@mzac
Copy link

mzac commented Feb 13, 2016

This project is great! Something I've been looking for for a while!

Do you know if this works with a Davis Vantage Vue ISS?

I've been running it for a while using ID 4 as my ISS is using that ID and not getting anything.

Also, I notice that it takes quite a while for it to hop from one channel to another. Is this normal?

root@kali:~/golang/bin# ./rtldavis -v -id 4
20:18:46.920810 BitRate: 19200
20:18:46.920902 SymbolLength: 14
20:18:46.920919 SampleRate: 268800
20:18:46.920935 Preamble: 1100101110001001
20:18:46.920950 PreambleSymbols: 16
20:18:46.920966 PreambleLength: 224
20:18:46.920981 PacketSymbols: 80
20:18:46.920997 PacketLength: 1120
20:18:46.921011 BlockSize: 512
20:18:46.921026 BufferLength: 2048
Found Rafael Micro R820T tuner
20:18:47.340303 main.go:68: {ChannelIdx:25 ChannelFreq:914899597 FreqError:0}
Exact sample rate is: 268800.001367 Hz
20:21:13.780850 main.go:96: Hop: {ChannelIdx:46 ChannelFreq:925436357 FreqError:-5312}
20:23:40.032595 main.go:96: Hop: {ChannelIdx:18 ChannelFreq:911387344 FreqError:-5501}
20:26:06.282853 main.go:96: Hop: {ChannelIdx:38 ChannelFreq:921422353 FreqError:-3555}
20:28:32.534173 main.go:96: Hop: {ChannelIdx:47 ChannelFreq:925938108 FreqError:-4092}

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 13, 2016

Theoretically, it should work with it but I don't actually own any Davis instruments devices so I don't have much opportunity to test.

This is still in very early development and I've not had a chance yet to write command line flags for all of the various methods to control gain and agc for rtl-sdr dongles. If you've compiled from source and your transmitter isn't near enough to your receiver, you may wish to recompile after changing the parameter from false to true on this line:

if err := dev.SetTunerGainMode(false); err != nil {

As for the hopping times, if it hasn't received a message for the time it takes the transmitter to make a full cycle of the pattern it will hop to a random channel. The period of the hopping pattern changes based on the ID of the transmitter according to the following:

p.ID = id
p.DwellTime = 2562500 * time.Microsecond
p.DwellTime += time.Duration(p.ID) * 62500 * time.Microsecond

DwellTime = 2.5625s + ID*0.0625s

DwellTime is the amount of time between each transmission on a new frequency.

I'm working on a more sensitive (and efficient) demodulator that should produce better results.

Also keep in mind that very little of the actual data decoding is done (or even correct), so the messages received are simply written to /dev/stdout as a hexadecimal string of the data received after verifying the CRC.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 13, 2016

Thanks for the reply, I tried changing the tuner gain mode to true and re-compiled and left it running overnight, but still nothing.

Just wondering if since I do have a davis ISS if there is anything I could provide you with more, ie some captures with gqrx? Do you think this could all be possible through gnu-radio also? I'm still a little new to the SDR scene but have a good linux background.

Thanks

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 15, 2016

Keep in mind that the -id flag is 0-indexed.

You might also want to give the new sdft branch a try, I haven't had a chance to do any simulations to see if it's any more sensitive than the previous demodulation method or not.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 16, 2016

Hi, so I cloned the sdft branch and re-compiled, got the laptop next to the vantage vue and still not receiving anything. I went into the diag screen (temp-hum together, then 2nd-chill) and I'm watching how the channel changes as referred in the manual on page 40:

7. Frequency index of the next packet to be received.*

http://www.davisnet.com/product_documents/weather/manuals/07395-261_IM_06351.pdf

From what I see, it changes channels sequentially from 0 up to 50 then back again.

Here is an image of what I see:

https://drive.google.com/file/d/0B66L23AG5UD-clZWZjF0XzFVOGpXa2puUXNRVFNKOXZWdGFR/view?usp=sharing

Also, does your code follow the next frequency index once it locks on? Could there be a CLI option to specify the starting channel?

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 16, 2016

Frequency hopping logic is implemented, it'll hop along with the transmitter once it's received a valid message. It's not really worth it to allow the user to specify the starting channel since it only takes ~2.5 minutes for it to make a full rotation of the hopping pattern.

Another possible issue is frequency offset error, rtl-sdr dongles aren't typically well adjusted and may be off several KHz which will interfere with the ability to receive messages. The demodulator on the master branch will do frequency offset error correction once it has successfully received a message, the sdft branch does not have support for that though.

If your receiver is too close to the transmitter it will likely be overloaded and not be able to demodulate the messages.

If you could make a few captures using a tool I've written I could take a look at them to see if the modulation format is different from the other transmitters I've tested with. See the documentation provided here to get a decent capture: https://github.com/bemasher/rtlcap

A couple of 10MB captures with the squelch and gain properly set should be sufficient to figure out what's going on with your davis weather station. Use flags -samplerate=268800 and -centerfreq=906871589.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 16, 2016

Sure thing I can do some captures. Do you have some specific CLI options you want me to use? Center frequency? etc?

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 16, 2016

Sorry, didn't get the info added until after you read it:
rtlcap -samplerate=268800 -centerfreq=906871589 [other flags]

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 16, 2016

Here you go, hopefully there is something there!

https://drive.google.com/folderview?id=0B66L23AG5UD-a2U0bjIta2tzSVk&usp=sharing

My cli:
root@kali:~/golang/bin# ./rtlcap -samplerate=268800 -centerfreq=906871589 -bytes=10M -o davis10

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 16, 2016

Please use the squelch feature as well, the documentation for rtlcap explains how to set an appropriate level.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 16, 2016

Ok I've re-run the test, took quite a while but should have better results.

https://drive.google.com/open?id=0B66L23AG5UD-cTB0Vms5QVJpUGs

My CLI this time:

rtlcap -samplerate=268800 -centerfreq=906871589 -gainbyindex=29 -squelch=1.7 -bytes=10M -o davis1.dat

And the sample output:

00:53:57.592652 Min: 1.533 Max: 1.578
00:53:58.567507 Min: 1.517 Max: 1.595
00:54:00.030311 Min: 1.522 Max: 1.590
00:54:01.005878 Min: 1.511 Max: 1.582
00:54:01.980983 Min: 1.521 Max: 6.383
00:54:02.955744 Min: 1.518 Max: 1.580
00:54:03.931373 Min: 1.526 Max: 1.580
00:54:04.906321 Min: 1.519 Max: 1.582
00:54:05.881318 Min: 1.524 Max: 1.578
00:54:06.856730 Min: 1.525 Max: 1.580
00:54:07.831835 Min: 1.529 Max: 1.576
00:54:08.806908 Min: 1.526 Max: 1.582
00:54:09.782077 Min: 1.514 Max: 1.576
00:54:10.756845 Min: 1.518 Max: 1.578

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 17, 2016

There are in fact valid Davis Instruments messages being transmitted. Ran it through the protocol test and shows that the value you want for the id flag is 3 -id=3 since the console starts at 1, but the protocol is 0-indexed.

$ go test -v -run=Parser
=== RUN   TestParser
18:55:19.197443 dsp.go:223: BitRate: 19200
18:55:19.197944 dsp.go:224: SymbolLength: 14
18:55:19.197944 dsp.go:225: SampleRate: 268800
18:55:19.197944 dsp.go:226: Preamble: 1100101110001001
18:55:19.197944 dsp.go:227: PreambleSymbols: 16
18:55:19.197944 dsp.go:228: PreambleLength: 224
18:55:19.197944 dsp.go:229: PacketSymbols: 80
18:55:19.197944 dsp.go:230: PacketLength: 1120
18:55:19.197944 dsp.go:231: BlockSize: 512
18:55:19.197944 dsp.go:232: BufferLength: 2048
18:55:19.202457 protocol_test.go:52: 83024A0E9809431E 03 7578  410
18:55:19.204464 protocol_test.go:52: 53024AFF72041D1C 03 38444   44
18:55:19.208976 protocol_test.go:52: E3024A800208DB5C 03 118457  185
18:55:19.212988 protocol_test.go:52: 23014A9FC0BD63A4 03 182082  322
18:55:19.219004 protocol_test.go:52: 83064A0EA8005EA4 03 278478  462
18:55:19.222513 protocol_test.go:52: 53024AFF70021BB8 03 333908   84
18:55:19.226525 protocol_test.go:52: E3034A800003A604 03 397526  214
18:55:19.230034 protocol_test.go:52: 73024A0001B8DC2A 03 457054  350
18:55:19.236052 protocol_test.go:52: 83034A0EC90AE4A2 03 541148  476
18:55:19.244075 protocol_test.go:52: 53024AFF700FCA15 03 662114   98
18:55:19.251093 protocol_test.go:52: E3024A80020BEB3F 03 783072  224
18:55:19.258285 protocol_test.go:52: 33024AF940BE95C2 03 895838  350
18:55:19.264802 protocol_test.go:52: 83054A0EE806DD7C 03 992220  476
18:55:19.273409 protocol_test.go:52: 53024AFF700B8A91 03 1121364   84
18:55:19.273911 protocol_test.go:52: E3024A800208DB5C 03 1135826  210
18:55:19.282432 protocol_test.go:52: 93024A0741943AA0 03 1264964  324
18:55:19.295467 protocol_test.go:52: 83024A0F0803CD8F 03 1484224  448
18:55:19.299477 protocol_test.go:52: 53024AFF72027DDA 03 1531448   56
18:55:19.304491 protocol_test.go:52: E3034A80020690C3 03 1615529  169
18:55:19.305995 protocol_test.go:52: A3044A3D38082A39 03 1638182  294
18:55:19.312011 protocol_test.go:52: 83044A0F1800331A 03 1750934  406
18:55:19.318369 protocol_test.go:52: 53024AFF710CC947 03 1839107    3
18:55:19.326891 protocol_test.go:52: E3024A80000DED9B 03 1976434  114
18:55:19.330901 protocol_test.go:52: 23044A9702BAE983 03 2031840  224
18:55:19.332406 protocol_test.go:52: 83014A0F3A0DA164 03 2058576  336
18:55:19.338420 protocol_test.go:52: 53004AFF700BCE12 03 2150839  439
18:55:19.343435 protocol_test.go:52: E3004A800008F9BD 03 2226721   33
18:55:19.347946 protocol_test.go:52: 73034A0001B5A7D6 03 2302604  140
18:55:19.351956 protocol_test.go:52: 83004A0F480F454C 03 2366192  240
18:55:19.357975 protocol_test.go:52: 53024AFF70047B7E 03 2454358  342
18:55:19.361483 protocol_test.go:52: E3014A800204F402 03 2497472  448
18:55:19.364490 protocol_test.go:52: 33014AF940B90BF7 03 2540578   34
18:55:19.366997 protocol_test.go:52: 83014A0F380CD727 03 2579596  140
18:55:19.373015 protocol_test.go:52: 53034AFF7105F23F 03 2675950  238
18:55:19.375522 protocol_test.go:52: E3014A800302A7F5 03 2719056  336
18:55:19.383044 protocol_test.go:52: 93024A0520847EEA 03 2835890  434
18:55:19.387054 protocol_test.go:52: 83034A0F5B0DDDFC 03 2895379   19
18:55:19.388056 protocol_test.go:52: 53024AFF700B8A91 03 2909812  116
18:55:19.395073 protocol_test.go:52: E3044A80000C303F 03 3010260  212
18:55:19.401088 protocol_test.go:52: A3034A403801469D 03 3110708  308
18:55:19.405599 protocol_test.go:52: 83024A0F890D04E8 03 3182478  398
18:55:19.408607 protocol_test.go:52: 53024AFF70074B1D 03 3233770  490
18:55:19.412617 protocol_test.go:52: E3054A8000050B47 03 3293254   70
18:55:19.418131 protocol_test.go:52: 23034A8DC0BA7AC3 03 3381402  154
18:55:19.423144 protocol_test.go:52: 83054A0FD802AF5D 03 3457262  238
18:55:19.428156 protocol_test.go:52: 53064AFF7000B2FC 03 3524920  312
18:55:19.431164 protocol_test.go:52: E3044A800203A7B2 03 3568008  392
18:55:19.434673 protocol_test.go:52: 73074A0000B15D65 03 3623376  464
18:55:19.440688 protocol_test.go:52: 83034A100A036EEE 03 3719708   28
18:55:19.445199 protocol_test.go:52: 53014AFF730F7194 03 3791458   98
18:55:19.449209 protocol_test.go:52: E3074A8000054FC4 03 3855005  157
18:55:19.456730 protocol_test.go:52: 33014AF940BE7B10 03 3971808  224
18:55:19.463253 protocol_test.go:52: 83024A101807E12A 03 4076314  282
18:55:19.472268 protocol_test.go:52: 53034AFF7007E14C 03 4221781  341
18:55:19.478542 protocol_test.go:52: E3014A80020C750A 03 4322198  406
18:55:19.485561 protocol_test.go:52: 93054A062094525F 03 4430798  462
18:55:19.491075 protocol_test.go:52: 83034A100A036EEE 03 4498431  511
18:55:19.491075 protocol_test.go:52: 83034A100A036EEE 03 4498432    0
18:55:19.494587 protocol_test.go:52: 53034AFF700A30E1 03 4553784   56
18:55:19.498096 protocol_test.go:52: E3034A80020C3189 03 4613232  112
18:55:19.502608 protocol_test.go:52: A3084A36380C1167 03 4684959  159
18:55:19.506119 protocol_test.go:52: 83014A0FE80AA2C6 03 4740309  213
18:55:19.510630 protocol_test.go:52: 53014AFF710C2795 03 4807948  268
18:55:19.516146 protocol_test.go:52: E3004A800008F9BD 03 4896066  322
18:55:19.518151 protocol_test.go:52: 23024A83C0B42A5D 03 4926842  378
18:55:19.522183 protocol_test.go:52: 83014A0FBA024B13 03 4974002  434
18:55:19.524823 protocol_test.go:52: 53054AFF700AFD64 03 5017066  490
18:55:19.529836 protocol_test.go:52: E3014A80020E5548 03 5092906   42
18:55:19.533344 protocol_test.go:52: 73034A0000B7B4A5 03 5148258   98
18:55:19.533846 protocol_test.go:52: 83014A0F880CC92A 03 5158557  157
18:55:19.535350 protocol_test.go:52: 53034AFF700D4006 03 5181152  224
18:55:19.539361 protocol_test.go:52: E3024A80030CA8E9 03 5244698  282
--- PASS: TestParser (0.34s)
PASS
ok      github.com/bemasher/rtldavis/protocol   0.371s

If you can provide actual temperature, barometric pressure, wind speed/direction and other readings I can use those to iron out some more of the protocol as far as sensor values and interpretations go.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 17, 2016

I'll try and do some captures tonight. BTW I found this, looks like they have decoded the protocol?

https://github.com/tridge/DavisSi1000

Here specifically I think:

https://github.com/tridge/DavisSi1000/blob/origin/Firmware/tools/davis_show.py

@mzac

This comment has been minimized.

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 17, 2016

I've seen the document and don't trust their assessment of the various
sensors and how their readings are determined.
On Wed, Feb 17, 2016 at 9:22 AM mzac notifications@github.com wrote:

Actually...

https://github.com/dekay/im-me/blob/master/pocketwx/src/protocol.txt


Reply to this email directly or view it on GitHub
#3 (comment).

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Feb 17, 2016

How so?

I also found a few other projects another based on Arduino using a RFM69W receiver, they seem to use the library that dekay has.

https://lowpowerlab.com/shop/index.php?_route_=moteino-r4

https://github.com/Scott216/Weather_Station_Data/wiki

https://github.com/dekay/DavisRFM69

https://github.com/dekay/DavisRFM69/wiki/Message-Protocol

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Feb 18, 2016

Popularity is not the same thing as correctness. I need to verify his results before inclusion.

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Jun 27, 2016

Hi, I haven't had a chance to look much at this lately but I re-compiled on a raspberry pi and I'm starting to get results.

One thing I noticed is that the data coming in is sporatic, this is probably becuase of the ISS changing channels?

My ISS is on ID 3

As you asked, you needed to know some values when the data is coming in:

19:34:40.781741 530174FF720EDC37
19:34:43.531600 830274336802E8F3
19:34:46.281814 330274FFC0B363E4
19:34:49.030209 E301742A010BA450
19:34:51.780770 530174FF7104282E
19:34:54.531083 83007433680E6DFC
19:34:57.281313 93007408E0773FA3
19:35:00.029969 E301742A0000260A
19:35:00.031964 E301742A0000260A

Current temp: 27.8 C
Hum:60 %
Wind: between 3-5km/h
Wind Direction: 163

Not sure if that'll help?

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Jun 28, 2016

The results are sporadic because it assumes your station is hopping at a different rate than it actually is. You'll need to specify the proper ID using the -id flag.

Keep in mind that the flag is 0-indexed. ID 1: -id=0, ID 2: -id=1

@mzac

This comment has been minimized.

Copy link
Author

mzac commented Jun 28, 2016

Yes, this time I was running it with -id=3

Could it be useful somehow to have the output show what channel/frequency it is receiving the signal on? Is the next channel always sequential? I seem to remember reading something about that in the documentation that it would hop from one to the next in sequence.

Restarted this morning and notice the gap between 7:11:08 and 7:11:41

root@pi2:~/go/bin# rtldavis -id=3 -v=true
07:09:03.338960 BitRate: 19200
07:09:03.339615 SymbolLength: 14
07:09:03.339677 SampleRate: 268800
07:09:03.339726 Preamble: 1100101110001001
07:09:03.339772 PreambleSymbols: 16
07:09:03.339821 PreambleLength: 224
07:09:03.339867 PacketSymbols: 80
07:09:03.339917 PacketLength: 1120
07:09:03.339966 BlockSize: 512
07:09:03.340013 BufferLength: 2048
Found Rafael Micro R820T tuner
Exact sample rate is: 268800.001367 Hz
07:10:35.561126 530074FF7100C2FB
07:10:38.310011 8300742B49005327
07:10:41.060164 9300740101977F9F
07:10:43.810417 E300742A000F7DB4
07:10:46.560980 530074FF7005A16F
07:10:49.311133 8300742B480CA19A
07:10:52.060071 A3007479380F9C06
07:10:54.809872 E301742A01032558
07:10:57.560070 530174FF70063B5D
07:11:00.310318 8301742B5807B9D3
07:11:03.060509 2301748B40B83989
07:11:05.808989 E301742A000B9761
07:11:08.559242 530174FF700FAA74
07:11:08.560817 530174FF700FAA74
07:11:41.557552 530174FF70014BBA
07:11:41.571308 530174FF70014BBA
@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Jun 28, 2016

Davis stations don't hop among the channels sequentially, but the pattern is fixed and the only variable between stations is the dwell time per channel which is governed by the ID of the station.

rtldavis will hop along with the station once it syncs up with it. It is also capable of re-syncing if it misses a couple of messages due to interference depending on the quality of the signal. I don't think you've selected the correct ID for your station though, which will negatively affect it's ability to re-sync in the event it misses a message. If your console states it's ID is 3 in the display, you need to use -id=2 when invoking rtldavis.

It may be a while before I have much time to continue work on this project.

@lehmanalan

This comment has been minimized.

Copy link

lehmanalan commented Dec 7, 2016

Hello,
I am new to this project and trying to get it to work for the first time. My experience is similar mzac's. I'm using a VantagePro2 ISS. I tried the master branch and then the sdft branch as suggested above. I have similar results from each. Any help or guidance would be most appreciated.
mzac: Were you able to make any progress?

Thanks,
Alan

Here is the output using the sdft branch:
pi@raspberrypi:~/go/bin $ ./rtldavis -v -id 1
05:07:27.054529 BitRate: 19200
05:07:27.054781 SymbolLength: 14
05:07:27.054820 SampleRate: 268800
05:07:27.054854 Preamble: 1100101110001001
05:07:27.054889 PreambleSymbols: 16
05:07:27.054922 PreambleLength: 224
05:07:27.054958 PacketSymbols: 80
05:07:27.054992 PacketLength: 1120
05:07:27.055027 BlockSize: 512
05:07:27.055057 BufferLength: 2048
Detached kernel driver
Found Rafael Micro R820T tuner
05:07:27.715645 main.go:68: {ChannelIdx:31 ChannelFreq:917910100 FreqError:0}
Exact sample rate is: 268800.001367 Hz
05:08:01.035525 E10000800300A091 1
05:08:01.035889 main.go:96: Hop: {ChannelIdx:50 ChannelFreq:927443359 FreqError:0}
05:08:04.974286 main.go:96: Hop: {ChannelIdx:37 ChannelFreq:920920603 FreqError:0}
05:08:07.601006 main.go:96: Hop: {ChannelIdx:12 ChannelFreq:908376841 FreqError:0}
05:08:10.227555 main.go:96: Hop: {ChannelIdx:13 ChannelFreq:908878591 FreqError:0}
05:08:11.534612 E10000800300A091 1
05:08:11.534859 main.go:96: Hop: {ChannelIdx:36 ChannelFreq:920418852 FreqError:0}
05:08:15.473344 main.go:96: Hop: {ChannelIdx:22 ChannelFreq:913394346 FreqError:0}
05:08:18.100085 main.go:96: Hop: {ChannelIdx: 3 ChannelFreq:903861086 FreqError:0}
05:08:20.726664 main.go:96: Hop: {ChannelIdx:21 ChannelFreq:912892595 FreqError:0}
05:08:24.659265 510000FF7300A75D 1
05:08:24.659677 main.go:96: Hop: {ChannelIdx: 2 ChannelFreq:903359336 FreqError:0}
05:08:28.598077 main.go:96: Hop: {ChannelIdx:30 ChannelFreq:917408349 FreqError:0}
05:08:31.224622 main.go:96: Hop: {ChannelIdx:42 ChannelFreq:923429355 FreqError:0}
05:08:33.851368 main.go:96: Hop: {ChannelIdx:18 ChannelFreq:911387344 FreqError:0}
05:10:12.283917 A10000291B006356 1
05:10:12.284354 main.go:96: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:0}
05:10:16.222783 main.go:96: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:0}
05:10:18.849320 main.go:96: Hop: {ChannelIdx:41 ChannelFreq:922927605 FreqError:0}
05:10:20.158336 510000FF7300A75D 1
05:10:20.158523 main.go:96: Hop: {ChannelIdx:25 ChannelFreq:914899597 FreqError:0}
05:10:24.096975 main.go:96: Hop: {ChannelIdx: 8 ChannelFreq:906369839 FreqError:0}
05:10:26.723526 main.go:96: Hop: {ChannelIdx:47 ChannelFreq:925938108 FreqError:0}
05:10:29.350186 main.go:96: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:0}

@bemasher

This comment has been minimized.

Copy link
Owner

bemasher commented Dec 7, 2016

I haven't worked on this project in quite a while. It's likely I won't have much time for this in the near future either, especially since I don't have any of the various base stations to test with.

@bytepoet

This comment has been minimized.

Copy link

bytepoet commented May 11, 2017

SUCCESS! Somewhat....There's large gaps but i'm assuming it's because i'm running the sdft branch?

16:12:35.479057 BitRate: 19200
16:12:35.480681 SymbolLength: 14
16:12:35.480794 SampleRate: 268800
16:12:35.480895 Preamble: 1100101110001001
16:12:35.480991 PreambleSymbols: 16
16:12:35.481086 PreambleLength: 224
16:12:35.481177 PacketSymbols: 80
16:12:35.481274 PacketLength: 1120
16:12:35.481365 BlockSize: 512
16:12:35.481454 BufferLength: 2048
Found Rafael Micro R820T tuner
Exact sample rate is: 268800.001367 Hz
16:16:22.278695 E000328803008D11
21:13:34.877297 A00032951B006CE9
21:13:37.441111 E000328803008D11
21:13:40.002478 500032FF7100451E
21:13:42.564785 8000322E4B005950
21:13:45.128326 2000324D018009CC
21:13:47.690055 E000328803008D11
21:13:50.253531 500032FF7300237C
21:13:52.815774 8000322E4B005950
21:13:55.377565 70003200C3805692
21:13:57.940717 E00032880100EB73
21:14:00.502891 500032FF7300237C
21:14:03.066730 8000322E49003F32
21:14:05.628179 300032FFC380F3E1
21:14:08.190421 E000328803008D11
21:14:10.753464 500032FF7300237C
21:14:13.315665 8000322E4B005950
21:14:15.877344 9000320003005A76
21:14:15.879415 9000320003005A76
21:15:32.753971 500032FF7300237C
21:15:40.441591 E000328803008D11
21:15:43.003992 500032FF7300237C
21:15:45.565714 8000322E4B005950
21:15:48.129279 300032FFC380F3E1
21:15:50.691131 E000328803008D11
21:15:53.255027 500032FF7300237C
21:15:55.816766 8000322E4B005950
21:15:58.378607 9000320003005A76
21:16:00.942127 E000328803008D11
21:16:03.503485 500032FF7300237C
21:16:06.067390 8000322E4B005950
21:16:08.629661 A00032931B00DE49
21:16:11.190960 E000328803008D11
21:16:13.754535 500032FF7300237C
21:16:16.316333 8000322E4B005950
21:16:18.879873 2000324D018009CC
21:16:21.441664 E000328803008D11
21:16:24.003811 500032FF7100451E
21:16:26.567787 8000322E4B005950
21:16:29.129068 70003200C3805692
21:16:31.690921 E000328803008D11
21:16:34.255733 500032FF7300237C
21:16:36.816235 8000322E4B005950
21:16:39.380149 300032FFC380F3E1
21:16:41.941978 E000328803008D11
21:16:44.503763 500032FF7300237C
21:16:47.067301 8000322E4B005950
21:16:49.629017 9000320003005A76
21:16:52.192593 E000328803008D11
21:16:54.754442 500032FF7300237C
21:16:57.316165 8000322E4B005950
21:16:59.880048 A00032931B00DE49
21:17:02.442284 E000328803008D11
21:17:05.004160 500032FF7300237C
21:17:05.005819 500032FF7300237C
21:21:16.132282 A000329219008F1B
21:21:18.695295 E000328803008D11
21:21:21.257930 500032FF7300237C
21:21:23.820498 8000322E4B005950
21:21:26.381861 2000324D018009CC
21:21:28.944093 E000328803008D11
21:21:31.507220 500032FF7300237C
21:21:34.070281 8000322E4B005950
21:22:53.507357 500032FF7300237C
21:22:56.071295 8000322E4B005950
21:22:58.634121 A00032931B00DE49

@markc1984

This comment has been minimized.

Copy link

markc1984 commented May 21, 2017

Hello,
I am posting my findings of this program. Just FYI, I have tried to adapt this program to work with a UK/EU based Davis Vantage Vue ISS with limited success.

The master branch never seems able to decode any messages, however with the SDFT branch it seems to decode channel 0 with each cycle but is never able to decode the 4 other channels. I have even tried to define an individual channel, adjusting their frequency in each direction in case of offset, however again, only channel 0 decodes while the other 4 are never able to do so.

For anyone who has a EU based Davis ISS who is wanting to try this, in protocol.go, change the frequencies to reflect EU frequency hops:

p.channels = []int{
            868066711, 868181885, 868297119, 868412292, 868527466,
    }
	
    p.hopPattern = []int{
            0, 2, 4, 1, 3,
    }

Frequency information was taken from http://madscientistlabs.blogspot.co.uk/2014/01/more-than-one-way-to-skin-cat.html (in comments) or https://groups.google.com/forum/#!msg/weewx-user/CnfOOu_OE48/_Yp_K04YBgAJ

As far as I'm aware, the hop pattern is correct.

In main.go, i also changed the dwell timer to reflect a full rotation + 1 (so 6 in total).

I am not sure if transmission of packets is different for EU models to the USA? Could this be why reception is sporadic?

@bemasher bemasher closed this Feb 2, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.