Archived Forum

Have you disabled the console output on the GPIO serial?

http://www.hobbytronics.co.uk/raspberry-pi-serial-port

Hi CyberGibbons,

  my problem is with the EmonTX not the Pi. I have the Pi working well with comms to the RF module working - as far as I can tell at the moment.

  My issue is with the EmonTX and the fact that the red LED stays lit.

thanks, John

Sorry, I didn't read that properly at all - on my phone.

I think that means that the RFM12B isn't initialising correctly.

When you say you haven't got a Arduino UART cable to hand, do you have one at all?

I'll have to look for a cable, I tend to use USB for my Arduino projects. If not I'll have to buy/make one and will take a few days to build/arrive.

John

Have you tried pressing the reset button? My V3 gives exactly the same symptoms when powered from the ac adapter, but after resetting it, all is OK. (Note to self - must track that down and tell Glyn! - probably it's something to do with the rate at which the power rails establish themselves.)

If it doesn't respond to that, I'll go along with the idea that the RFM12B is the likely culprit. If you look at the default code, then almost the first thing that happens is the LED is turned on, then the RFM12B is initialised. If that doesn't happen and it locks up there, then you get the symptoms you're experiencing.

If you have no ac supply, the LED will be on for 10 s, off for 1 s, then on again for a 2 s, then it won't flash again as it thinks it's battery powered and it's saving ampere-hours. But if you have an ac supply and no ct's, it should still do the standard sequence - 10 s on, 10 flashes, then a flash every 10 s.

But I don't understand why it worked once - unless there really is an iffy joint there somewhere.

Thanks for the help Robert. I did try resetting the board after power up (after giving it various delays) but that didn't help.

It would probably be a good idea that the LED is flashed during the reset cycle so that you know the board is running code... it could then continue with the 10s etc sequence.

I've found an old USB to serial converter and a PCB mounted D-Sub, so I'm going to try and make a USB to UART cable. If I power the EmonTX from the AC or USB then looks like I don't need the 5V on the UART... that just leaves GND, RST, TX and RX - that shouldn't be too difficult to get going.

John

Ok, Robert. You were right. After playing around with my USB to Serial converter it seemed that I could get the unit to boot if I had the ground connected from the converter to the board. I then played around with the reset and realized that I wasn't holding the reset button for long enough before. I need to have a look at the circuit as well because if I short the UART's RST line to ground then the reste happens immediately, more like I'd expect (that's how a realized initially that a reset would kick it into life too).

So, I can now get the EmonTX to boot if I hit the reset button after powering it. At least I think it's booting as it goes through the 10s red, 10xflash and then flashes every 10s with no CT's (AC-AC powering it).

I now need to connect it back up to the CTs and see if I can get it to communicate with the Pi.

That's about as much as I can do today - I'll get the scope out later in the week and report back on this thread.

Ok, I now have two CTs connected and the EmonTX communicating with the Pi... Pi is logging data and I just need to set up the inputs, feeds, etc.

Thanks for all your support today - I'll have a look at the non-booting at power up issue later in the week.

thanks, John

I'll see what Glyn has to say about this. I had a look at the information about the RFµ and the RFM12B but I'm not convinced the version I was looking at is accurate.

I have simply put a "delay(5);" immediately before "rf12_initialize(...);" at the top of the setup(...) method and that seems to do the trick. 2 ms was not enough, 3 ms seemed to be ok so 5 ms is probably enough to let the supply settle before attempting to initialise the RFM12B.

Thanks again Robert, I'll give that a try.

All seems to be working with my setup now. With one proviso about having to change the timestore directory in the Timestore.php engine source. Took me a while to find my way through the source but got there in the end.

For others watching this thread, if you follow the Pi harddisk setup guide then you end up creating a mount on /data with the timestore data in a sub-dir at /data/timestore. The emoncms/Modules/feed/engine/Timestore.php flle points to the old /var/lib/timestore directory so changing the source to point to /data/timestore did the trick for me.

In the git version I pulled Timestore.php line 15 becomes:

private $dir = "/data/timestore/";

Final post on this thread:

I have now updated the firmware on the EmonTx with today's latest updates in Git. The 10ms delay before initializing the RF module seems to have done the trick.

My board now boots reliably.

John

With further testing, I found that 5 ms wasn't enough over the full range of possible supply voltages, so I upped it to 10 (not that it makes much difference as a once-only event at startup).  I've also pointed out and Glyn has corrected another bug in the calculations that I spotted that doesn't appear to have caught anyone yet.