Archived Forum

I'm an experienced engineer, but new to openenergy monitor. What I can tell you is that I bought a RFM12Pi V2 a week ago, Built the SD card (IPE locked file system running Python) following instructions on this site. It receives data from RFM12 on the openenergy Tx Shield  fine, So I don't think this is a known or common problem, It is frustrating if you get a problem like this, as there are so many variables.

Make sure you've edited the Python config script and the Arduino sketch correctly, so that the frequency the software sets matches the hardware of both your RFM modules, and try putting the transmitter and receiver .so that you can eliminate weak signal as the cause.

I am an experienced engineer, too. RF protocol sends bytes over the wire and not strings (bytes converted into strings). The output clearly shows that the problem is communication problem between RFM12 board and RPi. 

If I do "t" command in minicom I get:

A?ailable commands:                                                            
  ?23 x ?    ? Tog?le c?nfiguration ?hange protection, 1?Unlocked              
  <nn> i     - set node ID (standard node ids are 1..26)                       
  <n? b      - set MHz?band (4 = 433, 8 = 868, ? = 915)                        
  <nnn> g    - ?et network?group (RFM12 o?ly ?llows 212, 0 = any)              
  <n> c?     - set collect ?ode (advan?ed, ?ormally 0)                         
  .?.,<nn> a - se??data packe???? node <??>, ?ith ?ck                          
  ?..,<nn> s - send da?a packet to node <nn>, no ack                           
?<n> l     ?- turn?activ?ty LED on?DIG8 on or off                             
Current configura?ion:                                                         
79?i15 g?10 @ 86??MHz  L??뺠1

As you see, no RF communication data, just help printed from RFM12Pi board.

I've desoldered low quality connector on RFM board and replaced with a decent one. Less errors, but still. Faulty RFM board? Frequency mismatch, RPi UART problem... I do not know :/

What software is installed, ready made image, apt-get package or did you follow a guide if so which one ?

Have you edited both the /boot/cmdline.txt to confirm it does not contain "console=ttyAMA0,115200kgdboc=ttyAMA0,115200" and the /etc/inittab to confirm this line (usually the last line) "# T0:23:respawn:/sbin/getty-LttyAMA0115200vt100" has the hash to commented it out ?

Is there anything else installed accessing the serial uart?

Paul

apt-get installation. I've removed both lines.

Weird character come only when RMF12Pi is emitting data, therefore I conclude it's a communication problem.

Yes.it is a bit odd. The RFM2Pi are normally very reliable and this issue is not something I've come accross before.

Since the "A?ailable commands:" are also corrupt it looks like a serial/uart issue, is there any other software running on the RPi that maybe trying to use the uart and clashing?. If there isn't then it may well be a hardware issue with the serial port, either with the Pi or the RFM2Pi. Not sure how you would prove either without substitution of one or the other.

You could try connecting the v3 directly to the RPi uart like this http://wiki.openenergymonitor.org/index.php?title=EmonTx_V3#Wired_Connectivity to eliminate an issue with the RPi.

Paul

I'll try that and I'll let you know...

Direct RPi <-> emonTX V3 communication works flawlessly. I've tried 2 different firmwares and they both work OK. But when I connect RFM12Pi I get corrupted chars over the serial.

Well I think that certainly suggests the RFM2Pi could be the cause.

Normally I would suggest trying to update the RFM2Pi firmware or reinstalling the firmware might be a better term as I would reinstall even if there wasn't a later revision, In this case, since the firmware is updated over serial, I think it would be wise to email the guys at the shop and include a link to this forum thread before considering a firmware update.

support@openenergymonitor.zendesk.com

Message received. We'll send out a replacement. Sounds like there could be some sort of fault. Strange, I've not experienced this before. I'll update this thread when I receive back the faulty unit and have a chance to debug myself.

Thanks a lot Paul for helping to debug.  

Thanks for excellent and instant response.

Today I received a new RFM12Pi. I've replaced the old one with the new one... and it works flawlessly. No corrupted data. Thanks.