Page 1 of 1
RFXCOM checksum errors
Posted: Sun Jun 21, 2009 9:29 pm
by lucaverdi
Hi there, I'm a newbi of this forum and I hope that all of you would bare my ignorance...
I've just set up a station
www.felino.info with an OS 928NX with all sensors working, I'm quite happy...
Then I've bought OS UV 800 sensor and OS pool water sensor 800 and an RFXCOM receiver.
Trying to connect RFXCOM to Meteohub I firstly had connection errors (due to rxcom 10001 port not set to 5500 that metohub search for)
This has been fixed:
logger (21.06.2009 18:02:29): station 1 (RFXCOM), error connect socket 192.168.1.17: port 5500: Connection refused
logger (21.06.2009 18:03:01): connect station 1 (RFXCOM via TCP/IP).
But after that lot's of cheksum errors appeared:
logger (21.06.2009 18:04:05): station 1 (RFXCOM), wrong checksum (00 vs computed 0e) for sensor model 08f8 (RFXmeter-8) in byte sequence: 60 08 f8 19 60 20 d0 18 43 20 d0 18 43
Any idea of what can I do?
Thanks so much to anyone can help!
Luca
Noceto (PR)
ITALY
:)
Re:RFXCOM checksum errors
Posted: Sun Jun 21, 2009 10:14 pm
by skyewright
lucaverdi wrote:logger (21.06.2009 18:04:05): station 1 (RFXCOM), wrong checksum (00 vs computed 0e) for sensor model 08f8 (RFXmeter-8) in byte sequence: 60 08 f8 19 60 20 d0 18 43 20 d0 18 43
Any idea of what can I do?
Have you tried using RFXCOM's RfReceiver application to look 'directly' at the data being received by the RFXCOM? That might help you see what is going on.
You can either point that application direct at the RFXCOM (but not while Meteohub is also reading data from it), or at the Meteohub port that acts as a pass-through for the incoming data.
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 8:03 am
by YJB
From my observations there are 2 main causes for this:
1) Poor reception of the Oregon signals by the receiver, try to reposition the receiver, or extend the antennae (it took me more than a month before I realized that the antennae can be extended, from approx 15cm to 50cm).
2) Conflicting signals. If you have a higher number of sensors, there is a bigger chance that they are (every now and then) interfering with each other, this happens especially when you have sensors that are transmitting on the same channel.
3) Meteohub being very busy. At least on my box I see (let me rephrase that, I'm under the impression that) a higher number of checksum errors when meteohub is very busy, for example when doing a recompute of all the history data. It might be that meteohub misses some infomration when it's send by the sensor.
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 8:29 am
by lucaverdi
Thanks YJB, to your kind observations:
1) the antenna is fully extended
2) I've got the UVN800 at 1mt from the rfxcom (I left it there to be sure to get signal ;)
May be there are conflicts on channels... (I've got an OS928NX with all sensors plus UVN800 and WTHR800, but these last should not be on same channels...)
3) may be busy NSLU2 ... the checksum errors where given during a recomputation (just after adding the new station...)
In a matter of hours I'll try with rfreceiver software as suggested from skyewright and let's see If I can get something good!
Thanks, I'll let you know!
Luca
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 9:16 am
by binbags
Hi
More food for thought. I have just had to strip my UVR138 down and fit ferrite rings on the data and power supply cables. This was to help kill unwanted interference from other stations and unknown rf signals. All is well with mine at the moment.
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 10:45 am
by skyewright
lucaverdi wrote:1) the antenna is fully extended
2) I've got the UVN800 at 1mt from the rfxcom (I left it there to be sure to get signal ;)
Try moving it further away! It may be that extreme proximity is causing the effect you are seeing.
2) I've got the UVN800 at 1mt from the rfxcom (I left it there to be sure to get signal ;)
May be there are conflicts on channels... (I've got an OS928NX with all sensors plus UVN800 and WTHR800, but these last should not be on same channels...)
So far as I recall that combination should run without conflict.
3) may be busy NSLU2
Yes quite possibly relevant, as mentioned by others.
In a matter of hours I'll try with rfreceiver software as suggested from skyewright and let's see If I can get something good!
One of the main reasons I mentined that was because your quoted checksum mentioned
RFXmeter-8 which I don't think you mentioned as one of your sensors.
Maybe the apparent (but bad checksum) RFXmeter signal is actually some result of having the transmitter so close to the receiver (i.e. some sort of swampling effect), or maybe there really is an RFXmeter somewhere in the neighbourhood, but not close enough for a good signal? Occassionally I pick up a stray signal from an OS anemometer 800m away!
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 10:58 am
by lucaverdi
All sensors moved away from receiver (at least 15 mt)
I haven't got any rfxmeter sensor, nor I think my neighbours...
Near the rfxrecevier I've got the OS console and a wifi router should they be the problem?
tried with rfreceiver.exe
This is the result
22/06/2009 10.54.40= 9C6C17C49C noise or an unknown data packet received bits=28 from SLAVE
22/06/2009 10.54.40= 6C17C414E4000814E40008 Buffer flushed due to timeout
22/06/2009 10.54.44= 20D01CA920 noise or an unknown data packet received bits=32
22/06/2009 10.54.44= D01CA9 Buffer flushed due to timeout
22/06/2009 10.54.46= 08F8 noise or an unknown data packet received bits=8
22/06/2009 10.54.46= 186108F8 noise or an unknown data packet received bits=24
22/06/2009 10.54.46= 1861 Buffer flushed due to timeout
22/06/2009 10.54.48= 44B4160144B41601 Buffer flushed due to timeout
22/06/2009 10.54.52= 28D80A06 Buffer flushed due to timeout
Luca
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 1:29 pm
by skyewright
lucaverdi wrote:Near the rfxrecevier I've got the OS console and a wifi router should they be the problem?
The OS console shouldn't be a problem, it too is only a receiver. The WiFi ought to be involved in a different part of the spectrum? I'm not sure if it would be relevant.
tried with rfreceiver.exe
This is the result
22/06/2009 10.54.40= 9C6C17C49C noise or an unknown data packet received bits=28 from SLAVE
22/06/2009 10.54.40= 6C17C414E4000814E40008 Buffer flushed due to timeout
22/06/2009 10.54.44= 20D01CA920 noise or an unknown data packet received bits=32
2
I'd expect to "see" all your OS sensors being picked up, i.e. the OS928NX's sensors as well as the new UV and pool sensors.
Are you sure you have the correct port set in RfReceiver?
If you are reading via Meteohub, then if you have more than one "weather station" the data for for weather station number X is on port 5500 + X.
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 8:51 pm
by lucaverdi
[file name=errors.txt size=18715]
http://www.meteohub.de/joomla/images/fb ... errors.txt[/file] Attached you can find screenshots and txt of logs...
I'm sure it's something stupid wrong... but i cannot understand what, it seems to misunderstand OS sensors with rfxmeter ...
Anyone can suggest config parameters (if any) of rfxreceiver ? I only changed via xportdirect the lan ip and port
Re:RFXCOM checksum errors
Posted: Mon Jun 22, 2009 9:11 pm
by YJB
Hmm, there is definetely something funny going on.
Background:
RFX-Meter is a separate device that allows you to attach power sensors or optical sensors for monitoring things like power, gas etc. It also transmit data packets in a similar way as your oregon sensors. If you don't have such a device, you should not see this kind of traffic. Also, if there was a RFX-mter within range, it should be a max of 3 consecutive numbers (like RFXmeter-40, RFXmeter-41, RFXmeter-42). Since you are seeing numbers all over the place it seems to me that you are picking up some random noise.
I would recommend that you contact Petronics (the manufacturer of the RFX-Receiver) and ask them for help, it might be that you unit is faulty, or maybe they've seen this behavior before and know how to troubleshoot it.
Re:RFXCOM checksum errors
Posted: Tue Jun 23, 2009 1:04 pm
by lucaverdi
SOLVED!
Thanks to Bert at support rfxcom.com
Thanks to everyone has helped!
Luca
:cheer: