Archived Forum

Did you buy the version with the correct radio frequency for your existing set-up? Is it within radio range of the base? If you change your emonTx to Node 19, does that still work?

I do not understand what you mean by Network ID and gateway ID in the emonTx. In the JeeLIb protocol, there is space for either the address of the sending node or the address of the receiving node, not both. We choose to use only the address of the receiving node, as we consider the source of the data to be important. Therefore, all receiving nodes receive all the data from transmitting nodes within range. They may choose which data to act on. For example the "multinode" Nanode base sketch chooses to forward each message it receives tagged with the number of the transmitting node. The emonGLCD receives energy data from the emonTx and time data from the emonBase, and handles the data according to its source node number.

I think you will find that, unless you have added these two items to the message payload and are using them for your own purposes, Network ID and gateway ID are not being used.

Yes, sure, I have correct frequency 433 MHz at all of my nodes, including emonTH. 

I have changed NODE IDs of my emonTX, 10,19 and current 20. All of them work without problems and corresponding NODE ID is shown at EMONCMS Input page.

My emonTX is based on Arduino Due and related modification of Emonlib from boredman available here:

http://boredomprojects.net/index.php/projects/home-energy-monitor

https://github.com/icboredman/EmonLib/tree/feature/12bit_3phase

If you look into related Arduino Due sketch:

http://boredomprojects.net/images/Articles/HomeEnergy/EmonTxDue.zip

you can see there at rows 8-11 definitions of NODE ID (sender), Networks (group) ID and gateway ID (receiver). Juts for this am I asking my question regarding "gateway ID". When I change Gateway ID to another one, then base station NODE ID is, there receiving od data via jeelini is stopped. 

But lets forget my emonTX for now. Im receiving data into basestation via jeelink/USB port. I can check received data via serial monitor in Arduino IDE. Each data set is represented by row of integers. But no data are coming from emonTh. Thats the matter.

If your base receives data from your emonTx when you set that to Node 19, it proves that the base will receive and decode Node 19. Therefore, I suspect that the RFM12B module in your emonTH is not transmitting, or is transmitting weakly. One final check: is the RFM12B module the correct one? (I know you bought the emonTH as a 433 MHz version). Photos to identify the version are here.

I think, I have isolated my problem. emonTH works OK, problem is another:

Part of my nodes is using library RF12 (or RFu_RF12) and rest is using library RFM12B (or RFM12B_Due from boredman). Nodes using one kind of library (RF12) are comunicating to each other properly, as well as other group of nodes (RFM12B) are comunicating to each other without problems. BUT - node from one group is unable to communicate with node from other group. It seems to me, that there is some incompatibility between libraries RF12 and RFM12B. Does anybody has a experience with this and how to push nodes with different libraries to communicate to each other?

Radek

You did not mention that you were using a library that is not our standard!

I think you are going to have to do some work on the libraries. It seems that your Boredman library has been derived from JeeLib with some changes specific to that hardware and it seems likely that the message format has changed. A similar thing has happened with the RFµ_JeeLib library to remove the lock-up problem that affects the RFµ-328, although in that case the message format remains identical.

The approach I would take is to find out the differences between the parent JeeLib library and the two child libraries, then incorporate the modifications of one child into the other. Which way to do this depends on what the differences are.

Yes, you are completely right. Boredman has used not Jeelabs clone, but Lowpowerlabs clone of RF12 library instead, which does implement some new features (for example 127 possible nodes instead of 31) but it lost backward compatibility due another packer header structure. To be honest, I dont understand, why boredman has used this "not OEM standard" of RF12 library for his modification to port in on Arduino Due. And to be honest twice, till last week I didn't know, that there are two incompatible clones of this library. :-)

So situation now is, I have two parts of my RF12 based network and one part is not communication with other one. OK, Im going to study differencies in detail and I have to decide, which one of these two RF12 lib will be my new standard. As I have tendency to respect standards, I do prefer OEM standard, but before I make my final decision, I have to check, whether or not is "boredmans" library better and why he used just this clone even if he went incompatible way.

Radek

It it is any help, there's a comment in emonlib.cpp that reads "modified to use up to 12 bits ADC resolution (ex. Arduino Due) by boredman@boredomprojects.net 26.12.2013"

So an email asking about the changes might be helpful.

Thanks for your tip, I'm in touch with boredman already for a longer period, but no progress. To be quite honest, using of Arduino Due based on my experience, seems to be a step in wrong direction.  12 bit resolution is fine, but I got very comparable results with Arduino Mega with just 10 bit res, but with more analogue inputs. From my perspective, based on my current experience, Due is too powerfull for this task and its 32 CPU brings more of disadvantages (incompatibilities) than advantages. Mega fits perfectly all the needs. For limited scope (just 6 inputs with 10 bit resolution) it seems to me to be perfect platform Arduino Yun. You dont need to setup any RF link, you just send data via onboard wifi. And when you use Arduino Mega as an input expander for Yun and you connect both boards via UART wires, you dont need more. At least I think so.