Archived Forum

Hello JetJackson, looks ok from here, everythings running as expected and i've checked a few accounts they appear to be working fine, I see your getting some data through but its intermittent? Could there be a connectivity issue on your end?

I've been running a ping test during the morning. I'm loosing about 2%. 342/11904.

So does the basefail by the temperature mean there is an issue sending data to emoncms?

"-emonBase fail-" on the emonGLCD means that more than 20 s elapsed between radio messages from the emonBase. That does not necessarily mean that the messages between the emonTx and the emonBase failed.

The radio messages that are sent are:

1. Power etc:      emonTx => emonBase & emonGLCD
2. Temperature : emonGLCD => emonBase
3. Time:             emonBase => emonGLCD

Thanks Robert,.

the base being the Pi? Hmm the LCD is sat on top of it. 

And the emonTH - do they send to the tx or direct to the base?

so do you think my problem is at home? What range is possible between the pieces?

"the base being the Pi? Hmm the LCD is sat on top of it." And that could be a problem! The signal will be overloading the input. It's possible to turn down the transmit power, but I can't tell you immediately how you do that, and it's a fairly advanced procedure anyway.

"And the emonTH - do they send to the tx or direct to the base?"  All the nodes that send data broadcast it to nowhere in particular. It is the receivers that decide whether they are interested in messages from a particular transmitter, or whether to ignore it. The base (in your case the RPi) usually listens for any transmitter and forwards or uses the data regardless, the emonGLCD only listens to one emonTx and the base by default. By default, the emonTx does not listen at all, except to check that no-one else is transmitting when it wants to.

I don't know where the problem is - you'll have to try to figure that out for yourself. There is no definitive figure for range. It depends on a lot of things - the construction of the building, what there is to absorb and reflect the signal, etc as well as distance. I set up an emonTx working across a garden (about 18 m) and then through a 200 mm stone wall - this is at 868 MHz. The usual figure given is 100 m over open ground. You can improve the range at the expense of data rate.

hmm.. well the LCD is actually working OK. It updates OK and shows all values and appears to be correct. The data just isn't getting to emoncms consistently. Some feeds are updating sometimes but minutes apart. Also some are showing as updated but with the wrong value.

(PS : Very frustrating as it was all going so well!!)

If you are using the shops SD card, you can use the troubleshooting guide at the end of this page http://emoncms.org/site/docs/raspberrypigateway to help see what is happening. It will enable you check the time & frequency of the packets arriving as well as the values.

From what you've told us above it sounds like intermitant & incomplete packets arriving at the Pi, possibly due to range which could be ruled out by moving the Pi to locations closer to emonTx/TH's (or visa versa) to test .It could also rf traffic clashes or interference this isn't so easy to test for but should be evident in the oem gateway logs.

Also check you don't have any redundant targets active in the oem gateway settings, if there are that will cause the gateway to be tied up trying to deliver to that target and may miss incoming packets whilst waiting for a response.

Paul

A quick update.

I've just setup my 3G enabled router and connected the Pi so its now connected over Three 3G rather than BT BB. It seems to be uploading via this route OK. 

This does point to a problem with BT. They ran all the checks yesterday and said the line etc was fine. No other changes have been made here. I've rebooted the HomeHub, swapped cables etc, but no change. It works for maybe 30s to a min then nothing for 5, 10, or even 30 mins.

I'm not really sure where to start with how to diagnose a problem on the BB. Web browsing is OK but its almost as if the BT path is blocking the data sent from the Pi?

PS  : Thanks for the troubleshooting  link I will have a read through it later today.

If that is the case it would be clear to spot using the troubleshooting guide as failed deliveries are logged, this would go a long way to prove the issue is definitely network.

Attached image is of the last few hours since the switch to the 3G router. No lost data and all OK. Damn you BT!! :-s