Posts made by Zeph

What is W3P? Is this some sort of CANBUS?

Some thoughts.

The last sleep study I had was simple - they sent me home with a recording device attached to two finger sensors; one was for heart rate and oxygenation, one was supposed to detect REM sleep (both had lights aimed at the skin or fingernail, did not appear to be accelerometers). I was surprised that they could detect REM sleep in that manner, but it would be worth looking into.

I wonder if one could detect movement with a cheaper BLE wristband, like the Xiomi MiBand? Not sure if anybody has cracked the OTA protocol. (OTA meaning generic Over the Air, not FOTA = Firmware/Flash Over the Air). I used to have one (before some firmware update from Xiomi bricked it), and it had a very long battery life and was small).

Building one's own wearable device - homebuilt and yet sturgy seems likely to be bigger and clunky; but maybe others can build tiny wearables.

Doppler Radar - I don't think my turning over in my sleep would result in a lot of motion towards/away the sensor from if mounted on the ceiling or high on the wall.

Antenna Effects (RCWL-0506) - might work if mounted close enough. Perhaps multiple devices. Worth considering. (These are NOT radar despite advertising, but do detect local movement).

One thing which might also work is a camera near the ceiling, attached to some image processing (NOT to a recorder!). Upside - it might be able to guess about movements of two people. In our case, we'd need to filter out cats who come and go all night (smaller areas?).

I recall reading a calculation which suggested that the LNA+PA version of the nrF24L01+ would not have a huge increase in range for a two-way connection with a regular transceiver; mainly because the receive side would not be much enhanced after SNR was taken into account (apparently the LNA was not that low noise, as the limiting factor for receiving). For one-way transmission from the PA unit or two way between two LNA+PA units, the improvement was much better . Was that post here?

Anyway, a higher gain antenna should help, as it increases signal strength and SNR in both directions. But is it true that higher gain is (almost??) always at the expense of a narrower emission pattern (kinda like using mirrors and lenses with a flashlight - the same power can be emitted weakly in all directions, or more strongly the smaller the focused beam)? And likewise for receive. For the example antenna in this thread, I believe the gain pattern is sort of toroidal - best at right angles to the antenna, less than unity along the axis. To get 9 db this would need to be a fairly flattened toroid (a stepped-on bagel). So in general, antenna gain is not an unambiguous "win", but rather involves a tradeoff which may or may not be worthwhile for a given system.

That can work well for a ranch style house which is mostly 2 dimensional, but for a multi story house the low transmit/receive gain along the antenna axis sometimes needs to be taken into account.

@tbowmo I agree with keeping things simple to implement, particularly on the Node & Gateway side. And it doesn't hurt that this would likely also keep things simpler to implement on the Controller side (ie: simpler plug-ins/adapters/drivers to write, which is a positive even when resources are not so tight.).

We might be able to nevertheless implement some kind of multi-value packet concept tho. I added a comment to the 3.0 doc about a simple and low overhead way to allow homogeneous arrays. That might or might not be worthwhile.

Robosensors's use case would involve some kind of tagged sub-unit approach, with multiple id/value pairs, yet another concept worth considering.

@tbowmo I made some related comments some while back when 2.0 was being developed, but then I disappeared from MySensors for many months (life does that). So I understand that it's too late for changes to that, and I am only planting seeds for the future, accepting that many will not sprout soon, or ever. The current spec is already a good effort.

The comments about more specific documentation can still be implemented, tho.

Perhaps I can help with comments on the binary protocol. The problem is that it has to map nearly 1:1 into the serial protocol, right? Or not?

I continue to be impressed with the quality of this community.

I've been gone for a while, but this seems like a nice next step. Feel free to move these comments to the forum if that make more sense. If it's too late for this round, perhaps they can be useful for the next revision.

1. I still think the controller (or if need be, the gateway) should do any neccessary conversion between metric and imperial units, rather than pushing it down to every node; it seems like some kind of violation of partitioning to push that UI customization concept (which in many controllers the user can toggle freely or even display both ways) down to the node level, where it adds unneeded complication. But I'll let that go.

2. It would be good to augment this with a systematic description of the underlying value type (int32, float32, string), and implied units if appropriate (potentially two units, for metric and imperial). For example, is wind speed in m/s or km/hr (assuming metric)? Is pressure in mmHg or hPA?

3. Aside from the type and implied units, there are a few hints given already - what 0 and 1 mean, an enumerated list of valid string values, color given a strings of hex digits, position as a multivalued structured string, etc. Keep those as notes in augmented docs as described in #1, and add more a needed (eg: IR commands)
   2A) Is there any logic to when enumerated values are encoded as integers, and when they are encoded as strings from a controlled vocabulary? Could we get by with one or the other, rather than this hybrid?

4. How do the semicolons internal to V_POSITION interact with the semicolons in the message field structure? If the same character is used for both, some note about that is needed. Or use commas in the former (substructured payloads) and semicolons in the former (overall message structure).

5. I'm glad to see that a distinction has been made between sensed light levels in Lux and uncalibrated light levels. Generalizing, I can see four types of possible reporting of such things. 1: uncalibrated results in arbitrary units (eg: ADC values of a LDR+resitor voltage divider), 2: scaled results 0-100%, 3: reporting in predefined units understood by both sides, like Lux, 4: reporting in uninterpreted units which can only be displayed but are not parsed. In the first case, I think the only thing to define for a given V_variable is whether brighter should be reported as higher or lower. This standard chooses 0-100% for V_LIGHT_LEVEL. Could't that be reported as V_PERCENTAGE instead? That is, use V_PERCENTAGE for any sensor reporting in scaled percentages.

6. If the protocol is going to allow for both uncalibrated and calibrated values (the latter in implied units), as with light levels, then I think it makes sense for the value with implied units to be the more specific variable; that is, V_LIGHT_LEVEL should be in lux, and V_LEVEL (or V_PERCENTAGE) would be used for the generic values, without units.

5A) V_LEVEL currently seems a little convoluted. It appears that the implied units depend upon which S_sensor the variable is associated with, which kind of breaks the pattern that units (if any) are implied by V_variable. And for S_DUST, S_AIR_QUALITY) there are no units. So for a calibrated light level in lux OR an uncalibrated dust level, use V_LEVEL but for an uncalibrated light level use V_LIGHT_LEVEL. V_LEVEL seems to be a grab bag of conceptually unrelated magnitude values, some with per-S_sensor implied units and some without. This could use rethinking. How about if V_LEVEL was used for any values which do not have implicit units (see #1 above), and V_PERCENTAGE was used if the value scales to 0..100%. Other V_variables could have pre-specified implicit units (metric and imperial).
5B) V_UNIT_PREFIX is really more of a suffix than a prefix. But this can work well with 5A above. If a value is reported as V_LEVEL then there are no interpreted or parsed units involved and the controller is not expected to be able to interpret or convert units. However, V_UNIT_SUFFIX could optionally supply a free text string with can be displayed after the value. So if you are reading a LDR and reporting the raw ADC value (or inverted value to ge the direction right), use only V_LEVEL. If you are reporting something in units not understood by the system, then use V_LEVEL and describe the units in V_UNIT_SUFFIX. (And if you are reporting percentage, use V_PERCENTAGE).

1. Semantically, there are two kinds of outputs: set-current-value which sets a new state to be retained, and trigger/command which performs some action once. It's kind of like edges and levels in hardware logic. Setting the same value twice is harmless, but issuing the same command twice may have different effects than sending it once. Most of the outputs are about set-current-value. However, some are commands - like sending an IR code.
   6A) What do V_UP, V_DOWN, and V_STOP mean? Unless they contain payloads to configure a (retained) movement speed or something, they seem more like commands/triggers rather than set-current-value. In that case, it makes more sense to have a V_SHADES variable which is set to 0,1,2 for stop, up and down (which are mutually exclusive), than to have three variables which could be set in parallel. Likewise with V_SCENE_ON and _OFF. These should be handled with one V_variable, much as sending a IR command. This is also easier to extend for an additional command to the same device - just define additional values to action associations, rather than needing to add a new V_variable.
   6B) (A shade controller which could set/report percentage opening could use V_PERCENTAGE)

2. Likewise there are two kinds of inputs: report-current-value and trigger-event. Mostly this protocol is about report-values. However the trigger functionality comes up in terms of V_TRIPPED, which is often implemented as a trigger. It should be made explicit what resets a triggered state: some systems use autoreset where after one report a device goes back to untriggered (trigger/event); other systems will keep reporting triggered forever until separately reset by some other means (report-current-state). We should be clear which mode this protocol expects.

It's good to see the ongoing refinement of MySensors and related initiatives! These are definitely meant to be helpful, not as criticism! Your work is much appreciated.

@gregl said:

isn't the key difference of the two that one 32u4 has a built in USB controller, whereas the 328p doesn't and relies on an external USB controller (FTDI usually.)

That's important, but there are many other differences vs ATMega328p. Offhand, there's an extra 0.5K RAM. Second 16 bit timer (Timer3) instead of 8 bit Timer2; plus high speed 10 bit Timer 4. SPI and TWI on different pin #'s (as seen by Arduino). More ADC pins, and a 10x/200x differential amplifier; different voltage ref (2.56v vs 1.1v). And various changes to interrupts or registers based on these. So some less-used libraries need porting, as well as changes to example code. Not sure how these differences affect the core of MySensors; you might have to try it out. There's a good chance that it would work, or that the changes needed would be minor.

The Leonardo is gone from the Arduino.cc product line, but the Micro is still sold so presumably the chip continues to be supported.

I was thinking to migrate to the Raspberry Pi (and try out various controller software).

However, I am hearing about problems with wear on SD cards; apparently the cards can fail after too many writes. There is no TRIM control as with SSD's, so there is limited ability to wear-level. So there are reports of periodic SD failures with 24/7 software running on a RPi. That would not be ideal for a home controller!

Has anybody had problems with this? Is some controller software better than others in this regard? (The problem can be reduced by using RAM disk (tmpfs) for highly volatile files).

@flopp said:

12v can be handle by the Arduino Pro min on RAW pin

Cars go well above 14V during operation (as well as having noise glitches on top of that). If the regulator is only good up to 12v, operation could be marginal. Hence the suggestion from @tbowmo of a couple of diodes in the power feed, to drop a bit of the voltage as seen by the regulator.

OK, let me see if I understand your overall flow.

You have your node connected to switched 12V power in the car. When you turn on the car, the uC gets power, when you turn off the car it loses power. When the car is cranking, the voltage drops enough that it tends to reset again (or else the cranking position on your key switch actually cuts off auxiliary power used by the uC).

So if you are at home and in range, loop() is called by the Arduino runtime just once; at the end of loop() the uC goes into an infinite busy loop rather than return, staying there until power is lost again. If you are away from home or the packets are lost for other reasons, resend() will cause a return from loop(), so that loop() will be called again by the Arduino runtime, so it will just keep trying until either power is lost, or it makes contact with your wireless network again.

Meanwhile every time it starts, the first byte of eeprom is incremented in setup(), and then loop() tries to fetch VAR1, and send VAR1+eeprom(0) back. If it succeeds, then the first byte of eeprom is zeroed.

Right?

That sounds reasonable. My immediate concern would be inconsistent operation during cranking, if the input voltage went just low enough to make the uC unstable. If your car's wiring cuts the power entirely, not a problem. Likewise there appears to be time for the uC to boot, and fully update eeprom, before losing power during cranking. (It's best not to be writing eeprom as voltage drops). It appears that those are not problems for your system tho.

@punter9 Thanks for the link, that gave some good background info, and some hope that those of us who are interested in playing with it will eventually be able to get one. (By pure chance, I happened to stumble across it minutes after it was first released, but didn't order one as I didn't have an immediate need, and I already have too many processors which I bought hoping to find a good use for already! Nevertheless I'll probably get one someday.)

I wasn't commenting on the quality of the hardware, just on the suitability for our purposes; parts which are only available in quantity one every few months IF YOU ARE LUCKY have some limitations.

From the article you linked, perhaps that will eventually change. We'll see. how soon. It's so cheap that if they don't keep limiting the quantities, one customer could buy up the full month's supply for embedding in a commercial product.

I'm wondering how it would be useful to us in DIY home automation tho.

As a node, I'm not seeing it as a major contender. Let's compare it to an Arduino Pro Mini (under $2 shipped). The minimal RPi zero plus memory, shipping and tax is going to be several times that.

The RPi Zero as node takes a lot more power to run and will not power up and down so quickly and gracefully, so it's not going to work well with battery power (and will have a larger passive load on mains power). It tends to require a whole OS which often gets in the way of direct interfacing with hardware, and requires system administering. There aren't as many sensor libraries for it. It has a much faster CPU and far more memory, but for most nodes that's just overkill. I'm not seeing that it would be competitive for most nodes even at the same price as an APM. But there must be some special purpose home automation nodes where it would be useful - any ideas?

Of course, it would work as server for some Home Automation Controller software. But you only need one of those, and how much money would it save once fitted out (relative to total system price) compared to using a RPi 3 (with built in WiFi and BLE) or RPi B+ @ $25, or BeagleBone Green?

So I'm still wondering what niche it would fill, within our domain...

What ideas do people have for making good use of a RPi Zero as a MySensors node, if it was easily available at the nominal price?

(Understand, I'll probably eventually get one to play around with because it IS cool, but not necessarily for HA. I also have a $9 C.H.I.P. on order, and a $19 PINE A64, and a RedBear Duo, etc. But those are to feed my addiction, I don't see them as changing the DIY Home Automation landscape).

If I understand, sometimes when you think you should be seeing 100%, the light is actually off?

You are counting on the triac to latch and hold until the next Zero Crossing. However a triac needs a certain level of current in order to latch. If you try to trigger it too early in the AC cycle (while the AC voltage is still close to zero, just starting to rise), the load may not provide enough current to latch the triac. This is especially true with some kinds of loads. For example, LED Xmas lisghts don't conduct until the AC instantaneous voltage rises above the combined Vfwd of 25-50 series LEDs.

One way to test this hypothesis is to lengthen the pulse. Or you could adjust your timing multiplier.

About 50% faster, uses about 50% more power, same memory.

Has built in WiFi and Bluetooth 4.1 (with BLE)! Uses tiny chip antenna on board, so who knows about the range. (There is an unpopulated SMA footprint, but no certification).

Most everything else is the same, for good compatibility.

Same price as the RPi 2 (which continues to be sold).

It's hard to take the Raspberry Pi Zero seriously. It's now over three months since it first went on sale, and it's rarely in stock anywhere for more than hours; when you can find it, you usually have to buy it with some kind of overpriced "kit" for $30-60, with a limit of one. If you did get one and you were to fry it, or want to build a second device using it, it may take you months to find another one. They've sold over 3 million Raspberry Pi 2's, so they know how to ramp up production if the want to. All this makes the RPi Zero seem more of a gimmick for "bragging rights" to a nominal $5 computer, than a serious option for our purposes, unfortunately.

@GertSanders said:

It seems you have removed the crystal and capacitors and plan to use the internal oscillator, I did this as well. Works most of the time, but uploading of sketches can give transmission errors of you go above 57K6 baud. Better to transmit at 36Kbit then (needs a change in the BOARDS.TXT file of Arduino IDE)

76K8 baud works better than 57K6 (division from 8 MHz has less error), and there are Optiboot variants which support it (with theBOARDS.TXT change you mention). Or 38K4 baud (half that) as you suggest, which is no more timing accurate than 76K8 but by being slower still may give more margin for sloppy edges or the like - if needed.

I am guessing that the babies could be repurposed as single unit mysensor nodes (integrated Atmega328 + nrf24L01+ on one small PCB). More expensive than an Ardu Pro Mini + nRF, and fewer I/O's, but perhaps useful for it's small form factor.

@cranky said:

Or that if the internet goes down, all my devices go dumb? Somehow

Or if the company sponsoring the proprietary cloud component goes dark or changes their terms of service.

No, you are not alone. There is a place for cloud based services in home automation, but for many of us, being in the middle of essential communications is not it.

@petoulachi said:

BTW, what is the F() function ? instead of Serial.print("Sensebender Micro FW "); why using Serial.print(F("Sensebender Micro FW ")); ?

It's a way to save some RAM. A simple string constant like "Hello" takes up 6 bytes of RAM and also 6 bytes of Flash (program) memory (6 bytes includes a single "hidden" byte of binary zero as an end-of-text marker). At startup and before your code executes, that bit of program memory is copied to RAM. The F() thing is a "macro" which causes the compiler save only the 6 bytes of Flash (no Ram used). The print function can (through C++ typing) fetch those 6 bytes from Flash at runtime for printing. If you have long or many text constants in your program, this can add up to some useful savings,when you only have 2K of RAM.

See the "F() Macro" on this page: https://www.arduino.cc/en/Reference/PROGMEM

So you find very close to 5V at the pixel chip level while running?

You are probably not missing something basic, but instead have a tricky marginal situation that's genuinely hard to debug.

If it was low power from the 5v charger (just not enough milliamps available), you should still be able to control, say, one red pixel on at a time, even if "all pixels white" overloaded the power supply.

The level shifting is one thing to check as others have indicated. Some 5v chargers run a little high (charge the battery faster?) which might make 3.3v logic driving data input of 5V pixel more marginal. You could insert a logic level shifter, or use a loose WS281x pixel running at the 3.3v between your Arduino and the first real pixel (adjust your code to send out one dummy black pixel before everything else).

Alternately, you could insert a resistor in the data line. in case it has to do with transmission line effects. Say, 47 ohms - give or take.

Also some of the cheap phone chargers have a very noisy power output. You might try using multiple bypass capacitors of differing values (eg: smaller ceramic for high frequency, higher value electrolytic for low, etc).

This is one of those times that a 'scope could be handy - maybe even one of the very cheap ones, used carefully. I'd really like to see a trace of that power line.

I'm noticing more and more often project descriptions (including here) are omitting schematics, in favor of pseudo-photo wiring diagrams.

I find good old eletronic schematics a lot easier to read and understand. At a glance I can see "Ah, they are using D10 for the interrupt, not D9, so I would have to change the code..." or whatever.

I would really love to see projects always include a schematic; if it's aimed at beginners who may not find that sufficient, I could see sometimes supplementing that with a wiring diagram too. Even for them, having a schematic too may be helpful - either to answer a question, or to help them become familiar and comfortable with schematics if they want.

Am I just an old fogey, or are there others who prefer schematics to wiring diagrams?

Soapbox off.

There are a potentially a couple of (related) issues involved here, regarding caps.

Voltage regulator chips often specify input and output capacitors, partially to reduce the ripple, but also sometimes in order to keep the voltage regulator internal circuitry stable. For the latter purpose the regulator manufacturer often specifies capacitor size (perhaps a range). Sometimes they also specify how much resistance the capacitor should have, called ESR: Equivalent Series Resistance. This part is very much dependent on the specific regulator. (As has been noted, a capacitor also has a max voltage, which should be at least 50% higher than the voltages you expect the inputs and outputs to experience; higher voltage increases the size). These caps should be close to the regulator (to help keep it stable).

AND - we have found that it often helps to use a cap near the power leads of the nRF24L01+. There is no specified size tho. Larger ones help keep the voltage steady during spikes in the current used by the radio. Smaller ones help reduce high frequency oscillation. Sometimes people have used both! (One to smooth high frequencies, one for low frequencies).

It is quite possible that the output capacitor for your voltage regulator will also serve to stabilize the nRF24L01+, especially if it's close to the radio as well as the regulator. You may just have to test, and see how reliable the radio is.

Keep the wires to the radio short; if you cannot, the cap close to the radio becomes more important, even if you have one on the regulator output.

@tekka said:

Maybe it's worthwhile noting here: if you upload a faulty sketch (e.g. failing to call gw.process() in regular intervals or hanging after startup) there is no way to recover OTA using dualoptiboot.

Ah. In theory, a DualOptiboot system would have a checksum of the new firmware written to external flash, and would not copy from external flash to internal flash until that was valid. I gather from what you say that this is not currently implemented?

This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.

Usually I get pretty stable and non-faulty transmissions, about 40secs to upload an average-sized sketch - besides that, MYSBootloader re-requests corrupt or incomplete FW blocks.

Cool. If MYSBootloader is reliable in loading new firmware OTA, I'm not sure what point there would be to the external flash method (DualOptiboot), at least within the MySensors ecosystem. Perhaps bootloader size?

If there was some way to embed a full library (ie: all functions needed by our sketches) for the nRF into the bootloader for OTA flashing, but also make it accessible it from sketches rather than loading a second copy of a nRF library, that could be a low cost variant (in terms of overall uC Flash).

OK, here's some background, for some eventual Wiki article or such.

So there are 4 main ways to get a program into the uC:

1. In System Programming (ISP) - uses SPI pins + reset, can program entire flash as well as fuses. This is how we get bootloaders into protected section of Flash. (There are also parallel programmers, and sometimes even additional methods like DebugWire or JTAG).

Using these methods is more cumbersome, so the Arduino folks chose to use "bootloaders" - a small program programmed (via ISP) into a protected section of on-chip Flash, and which can in turn communicate with the outside world and write (program) a compiled sketch into the rest of on-chip flash. The bootloaders are invoked by rebooting (or upon powerup) the uC.

1. Serial bootloader using Arduino bootloader protocol (subset of Atmel's STK500 protocol). A program in a protected section of uC onboard flash that can write compiled sketches into the rest of flash. Optiboot is the name of a particular serial bootloader used in many ATMega328p Arduino derivatives. (Not always used in APM (Arduino Pro Micros) but can be).

2. MysBootloader - similar to the serial bootloader, is a small program in a protected section of on-chip flash which can write compiled sketches into the rest of the flash, but it gets the data to write from special Over The Air (OTA) bootloader packets rather than via the serial port.

3. DualOptiboot - this is another OTA bootloader, but the idea is that you write the new compiled sketch (in binary) into an external flash chip, and then only after you have received and validated the entire new binary do you reboot and let the bootloader copy from external flash to on-chip flash. Called DualOptiboot because it's derived from OptiBoot and still supports serial bootloading as well.

With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into a sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the OTA bootloader. The DualOptiboot approach is perhaps in some ways a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast. Also, if all else fails, you can still open up the node and user serial bootloading. However, DualOptiboot only works when you have an appropriate off-chip flash memory connected, which limits your hardware.

I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would involve using a subset of the RFM69 library in the bootloader, and had not yet been done when this was written.

If OTA bootloading fails, you can try again (you may need to power cycle the node). You can reduce the distance between source and destination. You can open the node and fall back to normal serial bootloading (at least with DualOptiboot, maybe with future versions of MysBootloader). And of course there is the fallback of using ISP (assuming the PCB doesn't do something to the reset & SPI lines that breaks that option).

Since MysBootloader keeps requesting replacements for missing or corrupted OTA bootloading packets, it usually won't fail unless the node is really out of range or there is terrible interference.

Tekka points out below a different failure mode - suppose the bootloading was successful, but the sketch itself is faulty (bugs). A serial bootloader like OptiBoot takes control upon reset (which in modern Arduinos can usually be triggered via the serial connection using an additional wire), and goes into bootloading mode if it receives proper data on the serial port - or if not, starts the currently loaded sketch. This may also happen on power up. For an OTA bootloader there's no additional wire to trigger reset on the target uC. Tekka says that MysBootloader can recover and load another sketch OTA while for some bugs in a sketch, DualOptiboot cannot recover (without a manual reset).

I have a small nit-picky request - could we say "OTA Bootloading" when we mean "Over the Air Bootloading"?

We have also discussed things like the OTA payload format, which means the bytes actually sent over the air (versus over a serial link, for example). We can also talk about the OTA speed vs the SPI speed.

OTA just means "Over the Air", which can apply to several things, not just bootloading. If we keep this clear now, it won't be a perpetual confusion, when a newbie comes across discussion about OTA protocols and assumes it MUST mean bootloading protocols because OTA==bootloading.

And if this is too much trouble to keep clear, never mind. Not a deal breaker.

The RFM73 and RFM75 appear to be nRF24L01+ derivatives (not identical but very similar); still in the 2.4GHz band but with a little more power so they might have better range.

The RFM69* is a completely different family - operating at either 433MHz or 868/915MHz (same chip, different passives), and with a lower speed, narrower bandwidth - and very different electronics (both the analog/RF and the digital registers). It should have much longer range, because of the power, the limited speed, and the lower frequencies (which penetrate better).

I am still interested in the nRF family because I've invested in it, and it's used here anyway for other things (higher bandwidth applications). But if one was ONLY going to build MySensor nodes, the RFM69 family could be very attractive because range is probably more important than bandwidth for our purposes here.

Another interesting (albeit long) video testing range of various modules and antennae.

Ultimate nRF24L01 range comparison – 38:17
— iforce2d

The interoperability of different types is somewhat surprising. Some had only a 2/3 packet success ratio even at close range, but retained that for a long distance, for example. He did try cap vs no cap, and with "whip" (really more of a stubby or rubber ducky style) antenna parallel or with one pointing at the other. The unit with PA+LNA and shield was overall pretty good for range.

Regarding adding wires to the on-PCB antenna of a nRF24L01+ module, here's someone who used two wires (andcut some traces) to create a dipole. He knew that it was hard to really calculate the appropriate values, so he did empirical testing to find the best lengths, using a test program.

http://www.instructables.com/id/Enhanced-NRF24L01/

And is this from the same Pete or another one?
Cheap DIY NRF24L01 Antenna Modification – 02:48
— Pete B

And a 250VAC fuse is fine to use on 120VAC (and in fact quite common).

@Zeph said:

@Oitzu The range was greatly improved by using a far-aday cage.

Sorry, it was meant to be a throw-away pun, not an insight.

@Oitzu The range was greatly improved by using a far-aday cage.

You are fast responding tonight - I was just noticing that D10 is used for select for both radios and was about to edit or withdraw my question!

I'm still curious whether it could have worked (with different chip selects), but that's an unusual use case so probably nobody else cares.

By the way, do you think this could handle both a RFM69 and a nRF24L01+, or would they interfere too much with each other being so close (ie: choose one)? (Even tho the RF per se is on different bands).

Small suggestion - mark pin 1 with a square pad in the next revision.

Also, are the battery terminals close to but not quite 0.1" from the MySX connector? Being clearly separate (like 0.15") could help avoid misplacement of a connector in some case.

Overall, tho, pretty cool!

@Anticimex said:

By the way, I did notice a typo in the MYSC spec. It says that it is recommended to support 24V on Vraw but the core team has agreed that 12V is more reasonable. So the spec will be updated to 12V.

A nominal 12v power input is good, but it would be nice to have some slack, like accepting up to 14v. Some inexpensive 12v sources can put out higher than 12.0v (even over 13V) when lightly loaded; likewise a fully charged lead acid battery. If the caps and regulator of a power user are spec'd to at least 14v, we can relax about these.

However a source should aim for 12v, not for the upper limit of acceptance (eg: 14v).

I would not think that the speed SHOULD make a difference. Since you can download programs, and and print to Serial at the expected baud rate, the appropriate seed info should be in the defines.

Have other people here had success with the DHT-11 on a APM at 3.3v/8MHz?

Given that I don't yet know where else to look, if I were you, I might try a quick standalone program that just prints the temperature & humidty to Serial every little while using the standard library, then try another library (I believe there are several). If some library does work well, that would give us a clue. If all libraries have the same problem, then, well, we can go from there.

Have you tried more than one DHT-11? Just in case it is in some way marginal.

You don't mention the frequency and voltage of your APM. If it's 5V and 16 MHz and multiple APMs fail the same way, then I'm at a loss. If it's lower voltage that could affect the DHT-11; and I suppose that 8 MHz could affect timing.

I'm trying to imagine what could be different to allow your Nano to work.

Nano's typically run at 5v/16 MHz even tho they have an additional 3.3v supply on board. And the 3.3v supplies from a Nano and a 3.3v APM could differ - perhaps the DHT-11 is marginal and small differences in voltage make a difference.

The wiring is easy to describe.

Put a fuse in line between the "hot" mains AC input and the power supply module input (the "neutral" can go directly to the power supply). Put a MOV across the power supply input (on the PS side of the fuse).

For small spikes, the MOV would protect the PS by absorbing most of it. For longer surges, the MOV would cause the fuse to blow, probably sacrificing itself in the process.

Maybe others can help with component selection (for 120v and 240v mains). I see that in the case of Littelfuse, the fuse is rated by RMS AC voltage, so a 140v MOV would work for a nominal 120VAC mains). http://www.littelfuse.com/~/media/electronics_technical/application_notes/varistors/littelfuse_selecting_a_littelfuse_varistor_application_note.pdf

I don't know if RMS rating is standard, or if some are rated by their DC voltage conduction threshold, but one would want to be sure of that for the brand they are getting.

Wow. A little better!

I assume that's at 250 Kbps? Did you do any range tests at different speeds?

The nRF24L01+ with LNA & PA & antenna is not that much more expensive than the rfm69* so for some applications that need the higher speed they are still in the running even with longer distances.

I saw an analsyis (maybe here?) which suggested that this setup would not do very much good for reception, which was more limited by the noise floor, such that the antenna gain and LNA would not improve things much - so most of the range gain would come from the increased transmit power (including antenna gain). This was a theoretic analysis, not an empircal test.

If true, it would mean that using an enhanced power unit on one end of the link only would not give one much additional range in bidirectional protocols, where the back-link (conventional to enhanced) would be the limiting factor. I've been curious if this is indeed the case or not in practice.

The domes are kind of cool for some things, but I think for this purpose I'd actually prefer flat stickers that fit smoothly on any side of a project box, even curved, without protruding and looking like something that should be pressed, or that should light up.

(OTOH domes atop an illuminated button (assuming translucent backing) would be awesome in some cases)

And with flat, (re) distribution in small batches is easier - one could get a lot of them in a minimum-postage conventional letter.

I like the idea of logo stickers. Better in some ways than typical swag like t-shirts and coffee cups, because if it goes on the devices we build that provides useful information, not just advertising. Maybe leave a blank section where a node number could optionally be written in with a sharpie, or a version.

Maybe "Networked by MySensors.org" rather than powered? ("Telepathy by MySensors"?)

I would guess that you are using the stubby linear antennas, with both antennas parallel to each other and at right angles to the line between the units. Like both antennas pointed up, with the units at some horizontal distance from each other. (The antennas will radiate/receive best at right angles to where they are pointing, and least along the line of where they are pointing - both directions - so pointing the antennas at each other is not good.)

Have you tried reducing the power level?

Do you have any regular models without PA+LNA+external antenna? You might try interoperating with them, for another data point.

RF is weird sometimes.

Thanks for the input so far!

Serial, but I was thinking of moving to an ethernet gateway - is there something I should know about that in regard to UI7?

It sounds like I should at minimum wait a bit before moving to UI7, since I do also have Z-Wave devices.

EDIT: Yowsa - reading the forum link above makes the latest UI7 release sound like a disaster!

AltUI sounds very good, great tip. Apparently it can replace the UI per se for both UI5 and UI7. Any advantage to using UI7 over UI5 underneath it?

Reading so far on AltUI, it says "Plugin authors should be able to control the display of their device using a simple javascript functions , even on the dashboard page. Should not be limited to a VERA Box api or any complex undocumented json behaviors. Just a dynamically loaded javascript which can make full use of bootstrap & useful libraries provided"

So how well does MySensors work with AltUI? Does it take advantage of the above?

@Francois

The pin labeled "d00 irq2" looks like Arduino digital pin 2 (aka int0). Right?

Could be power I suppose. You say that it reboots OK with other sketches. Do both the relay and temp sensor single-sensor sketches reboot OK?

I was assuming so, which is why I was thinking something software rather than hardware, but assuming is what gets us stuck, debug wise.

Background - I have a Vera 3.

Skimming for UI7, mostly I see posts about problems, and some (old) comments about not much useful in the upgrade. But they are trying to get people to switch, reducing support for UI5.

Is it time to switch to UI7? Have the problems been well enough addressed? Have any advantages (other than ongoing support) come to light since then?

How much RAM do you have left?

I don't know if it's related, but it's one of the first things I check (nowadays, having too little remaining hair to spare) when things go weird and I have no other good hypothesis. If there's plenty of RAM left, I keep looking for another cause. (I don't currently have any theory about what really happens when you try to reboot - if it successfully gets all the way to a uC reset and hardware reboot, then memory would be reallocated from scratch so this would not apply, so an out of memory bug would probably have to happen earlier in the process).

What matters here is the space between the stack and the heap (without tracing any freed blocks on the heap to get total free memory). I use a variant of this technique which uses very little program and data memory:

http://forum.pololu.com/viewtopic.php?f=10&t=989&view=unread#p4218

@petewill just to be clear - I appreciate your posting that adding the loose wire to the on-PCB antenna helped, and I'm not discouraging that. If it works, it works! Mostly I wanted people to understand that it's going to be trial and error, rather than something where they can count on calculating the best length (because it's added to another antenna at an unanticipated point, rather than being a standalone wire antenna). It would not surprise me if somebody found that a 6.5 cm wire worked better than 8.33cm, for their particular case (picking an example length at random). Wiggle those rabbit ears!

I love the examples you post and your excellent videos. I have modestly good knowledge here and there, with gaps in other places, and your working examples give me confidence/inspiration to build something I haven't before - along with practical (not just theoretical) advice. You even turn your minor mistakes into lessons - how it should have been done, and how you managed to work around it anyway. Keep them coming!

One thing to note is that adding an external antenna extension to the on-PCB antenna moves this into the realm of "RF magic". What I mean is that it becomes a very non-standard sort of hybrid antenna about which we can predict very little. Like receiving television with rabbit ears and aluminum foil, you will mostly have to work by trial and error rather than exact calculations.

The on-PCB antenna should already be tuned for the RF wavelength, probably near the middle of the band. We can also calculate the appropriate length for a straight wire used INSTEAD OF the on-PCB. But when we solder a wire onto the PCB antenna, we wind up with a very complex antenna which may or may not work very well (but in general it's far easier to make a random antenna work poorly than to make it work well). There are questions of antenna gain (or attenuation), but also of directionality - adding the wire might make it transmit/receive better in some directions and worse in other directions!

Part of my point is that we cannot necessarily predict the best length of wire to solder to the on-PCB antenna by using the calculations that would apply with no PCB antenna. It may depend where on the PCB antenna trace you solder the extra wire, and perhaps on how the wire gets bent (especially if it comes near electrical conductors).

So after you have the node placed where you want it (including the orientation), you can try moving the added antenna around in the case for better reception - and you can also try changing the wire length because 8.33 cm is not necessarily optimal for this hybrid antenna. Of course it's easier to shorten a wire by just successively chopping off a little bit at a time; you can solder in a new wire if need be.

The length does not have to be super precise by the way - a loose wire antenna is not a highly tuned (Hi-Q) antenna and a slightly suboptimal length doesn't dramatically alter the results. Which is good, since the modules operate over a range of frequencies - and because even without the PCB antenna to really complicate things, even the PCB trace between the chip and the wire is part of the tuning as well, not just the bendable wire.

Stranded wire vs solid should not have a large effect, compared to the many other factors involved here.

I had to check, tho, that this wasn't a post from April 1 that resurfaced... especially with the twitter status.

And I wonder if the methane sensor would really work in that application.

With all those sensors and wires, the Spousal Acceptance Factor might be a challenge, unless you meticulously handle all the cleaning duties.

If the fellow behind http://lygte-info.dk/info/usbPowerSupplyTestHow UK.html posts good results on his website, the supply chain should prepare for a flood of orders! I've seen those tests widely referenced, and I think a lot of people are looking for something safer but still cheap.

Don't be surprised if a positive review made it to HackaDay and the like as well.

(Get your ali orders in now, beat the rush - if you think it will come out well)

@NeverDie said:

@Zeph I'm pretty sure the blob modules are using the RFM75 die because the above mA and uA measurements appear to be a good match for the electrical specification on page 22 of http://www.hoperf.com/upload/rf/RFM75 Datasheet v1.0.pdf

Could you see if they work on channels above 84? The RFM75 lists fewer channels than the nRF24L01+, which is probably for regulatory rather than technical reasons (the frequency band does extend further in another part of the spec). I would be curious to know if channel 125 works, for example.

@TD22057 said:

I'm seeing similar results with my radios. ... The two types seem to be able to talk to each other OK but if set two modules at opposite ends of the house (with 2 exterior walls in between as well), the cheap modules still connect and the genuine ones don't. I'm assuming this is similar to what you're seeing with the real modules having a lower transmit power.

My hypothesis: The blob units have more transmit power (perhaps being Si24R01 or related) and thus a higher first peak, but perhaps no better receive sensitivity.

If so a blob to genuine would have at least as good a range as blob to blob, and a genuine to blob would have similar range as a genuine to genuine.

Of course testing that may involve a one way transmission, where we check for lost packets on the receive side (without expecting a round trip).

If however the blobs have managed to beat the genuine receive sensitivity, then they are really hot stuff!

You've nailed it indeed.

I'm guessing that the first peak on the blob chips is higher because it has higher RF output as well.

If you set bit 0 of register 6 to a 1 on the Blob (unused on the nRF24L01+), and if this chip is a Si24R01 or derivative, it will switch from +2~3dBm to +7dBm RF output, and probably draw even more power.

If you want more than one kind of module, you can ask the eBay seller to combine shipping.

@Sparkman said:

For me it's primarily a cost driven decision. I can get a Pro Mini and an NRF24L01+ for a total price, including shipping to Canada, for less than $3US in total. The cheapest RFM69 module is $3.90 + $6.55 shipping and then the cost of a Pro Mini. A Moteino equipped with a RFM69 is almost $20, not including shipping. At some point I may experiment with different RF modules, but so far the NRF clones/fakes have been working fine for me with coverage throughout the 3 levels in my house and in our yard.

Cheers
Al

I didn't realize that shipping for the RFM69* is so expensive to Canada. He advertises them both at the anarduino website and on eBay, if one of those is cheaper for you.

Your point is well taken. Note that anarduino has been promising stripped down versions without the RTC and large external flash (but with the radio) which might close the gap somewhat. Updating the website with new products seems to be low priority tho...

@NeverDie said:

I looked into the JeeLabs forum recently, and it's practically deserted. Too bad, because in general I likel the direction jcw is headed. At the moment it appears that he himself isn't on that forum either, so questions aren't getting answered.

Broadly speaking, there seems to be a bit more life on the moteino and anarduino forums.

Yeah, it was once a more active community, but may have been bypassed by newer competitors - including MySensors.

However what I was recommending - in general, not specifically for this topic - was his blog, since 2008. He has covered many topics of interest to people designing wireless sensor networks and low power nodes. I used to check in at least weekly. It used to be notes on whatever he was investigating at the time; while it still has some of that flavor it nowadays is more tutorial in structure, like a book in progress [which it is], which is fine too.

End of sidetrack.

I have not been involved in porting Arduino based sensor libraries to new architectures.

I would expect that some of them are built on top of the standard Arduino/Wiring libraries, so if the latter have been implemented, the sensor library would be OK. Eg: if the same i2c or spi calls can be made, some sensors should be fine.

The problem areas I would imagine are:

• Libraries which depend too closely on the uC hardware and onboard peripherals (eg: assume they can use Timer2 for something)
• Libraries which require assembly language or instruction counting for tight timing.

It would be interesting to assess which libraries often used by MySensors nodes would fit in each category. Is there anything like a list of the libraries used by MySensors code or examples?

Agreed about the Arduino IDE being dear to the heart of MySensors.

So for the moment the nRF24LE1 is an interesting offshoot, rather than the main development direction. I can imagine some common node types being implemented that way as cheap/tiny special purpose options, but at the moment I think flexible roll-your-own-mixture nodes will continue to use the Arduino IDE.

If RedBear gets their Arduino IDE for the nRF51822 solid ("A work in progress" it says), that may become very tempting for some applications.

RSSI could be nice. I seem to recall their soft device has 8 pipes rather than 6, but we don't use them in a pipe-limited fashion. Not sure what other OTA advantages it would have in a MySensors application. Otherwise it's just cool to have the transceiver and uC in one module, with a more powerful uC (faster, 32bit, more memory).

I keep wondering that some Chinese vendor doesn't combine an APM and nRF24L01+ on one PCB. That could be a killer, at least in our circles. (Prepare for more interference!)

Meanwhile - onward nRF51822 !

Ah, OK.

I saw the testing as serving two purposes:

• Learning a "power signature" to distinguish variations on the chips
• Finding out how bad (or good) the variants are in regard to power usage

Seems like the first is nailed. The latter has begun to be characterized (thanks to you). The idle and sleep power is substantially greater on the blobs (for example). If the 8.4 ma for Receive is for the blobs, that doesn't sound bad, don't know about transmit.

And if powered by the mains, it doesn't much matter.

The original MySensors architecture used a stand-alone Home Automation contoller, the Vera. This was not going to directly handle the nRF24L01+ radio transceivers and the OTA (Over the Air) MySensors protocol, so the second component was a Gateway which connected to the controller via USB serial, and directly to the nRF (an Arduino Nano filled this role well, with both USB, and a 3.3v power supply for the nRF). Then the nodes have an Arduion (Nano can work, or Arduino Pro Mini, or many others) with a nRF and sensors/actuators.

Later it became possible to use ethernet (rather than USB) between the controller and the gateway. And other transciever types may be substituted for the nRF as the radio link, but the architecture looks about the same.

This architecture with a gateway arduino in the middle can potentially work for other standalone Home Automation controllers, or for PC based (Windows, Linux, Mac) controller software.

But then the Raspberry Pi comes along. It's powerful enough to run some Home Automation software AND it can interface directly to a nRF24L01+. So it's possible to run both the controller and the gateway functions on a Raspberry Pi, without needing an external gateway.

That's going to be about as cheap as you can get.

The part you left out is powering it, which could cost more than the uC, nRF and switches - or not.

Cheap power. There are some very cheap and small 5v USB "phone charger" plugs (eBay, AliExpress, dollar stores), which could be reduced to 3.3v (needed by the nRF) by the regulator on a 3.3v APM. The couple I've opened up could have their PCB removed from the AC plug tines and housing without much trouble.

Power Quality The cheapest ones may put out noisy 5V - intended for recharging batteries at best. Be sure to check the voltage. The regulator on the APM might be enough, or you might need more caps to smooth it.

Safety And some of the cheap ones have poor isolation between the AC mains and the 5VDC output. You can search for some of the investigations thereof on the web. The worst case would be mains and DC traces too close to each other, or a poorly insulated transformer.

If the buttons will isolate a user from any potential shock, and you disconnect the power before working on them, and you choose a phone charger which is not too bad, you might make a switch node for $3-4. But don't hold any of us responsible for your safety!

AND - you may have cheap power already figured out.

Have you decided to toss the blob modules (or put them in the back of the drawers), in favor of genuine Nordic only?

Besides RedBearLab and eBay - Adafruit has a couple of interesting nRF51822 boards, Nordic itself has a development board and a dongle for reasonable prices, AliExpress has more of the cheap boards and chips. SEEEDstudio also has some boards.

And a few of these work with mBed.

There is work to support this chip with the Arduino IDE by RedBear at least.

The topic of this chip has arisen before on the forums. It looks like it could be very interesting, albeit a bit more expensive than the nRF24LE1 for which there is a Proof of Concept implementation for MySensors. I've been expecting a nRF51822 / MySensors implementation for a while, and was surprised to see the nRF24LE1 first.

And Nordic is starting to release the next generation, the nRF52 line starting with the nRF52832 if I recall correctly. Preview DK is out but no chips till the end of the year. Seems similar but with a Cortex M4, faster,more memory - and integrates ANT+ and NFC as well as Bluetooth LE and legacy protocols (like nRF24L01+ and ESB).

I've really been wanting to explore this family, just haven't had time yet. I will be watching carefully anything you come up with.

I understand about other deadlines - I appreciate the efforts you have made so far.

Sounds like all that's needed in the final version of your testing is a bent-pin 2x8 connector test shim such as you have described and photographed, and a $400 DVM

Register 6 (RF_SETUP) bit 7 (CONT_WAVE) on p 55 of the rev 1 datasheet.

Set it up to transmit constantly (carrier only, no data) and measure the Vcc current usage. (For a short time obviously!) Probably close to the current it would take while sending data.

Likewise, measure current while waiting to receive with no actual data coming in (unless that's what your standby is).

I haven't tried the constant-wave transmit mode, I just remembered that it was mentioned in the datasheet.

Checking aliexpress:

http://www.aliexpress.com/item/NRF24LE1-NRF24L01-MCU-Wireless-Transceiver-DIP-Wireless-Communication-Module-nE/32230173245.html

At those sizes and prices, this could be a very interesting option. Looking forward to hearing about your progress.

@NeverDie - now that you have the measurement down, how about measuring receive current, and perhaps carrier-only transmit current? Both of those can be steady state.

I'd still like to know how the various models rate in those areas too, while you have the setup handy.

Those with a low idle/sleep power usage are either Nordic or a quality clone.

Even the blob modules would be workable in non-battery nodes, if they indeed have excellent range and low packet loss.

So I just looked up the Fluke 87V, and the price is a bit high for my budget. So alas, the current state of our fake detection (pun acknowledged) is not a universal solution.

Perhaps a variant with a coulomb counter will arise. Or perhaps using the 200x amplified differential ADC input of the Leonardo or Mega2560 with averaging.

And I think it would be very apropos to distill the knowledge from these many posts into a wiki page. As with many threads here, there's some great info but sometimes it's embedded in hours of reading to find it again.

Hmm.. no.. but I cannot for my mind recollect where I could have read it. So it might just have been a creation of my (weird) mind.

Er, check the second sentence of the first (real) paragraph of the OP of the earlier fake nRF24L01+ thread.. Maybe that's where @hek got that impression.

And now I am the one who doesn't recall exactly where I read that - but it's undoubtedly from one of the sources I linked to in that post, raised as one of the reasons to be concerned about fakes.

Great work indeed!

However, the source link (at this time) fails...

There's a lot of positive to say about using subGHz transceivers and the RFM69* in particular for low bandwidth sensor networks.

I wouldn't go there just because of the fake nRF24L01+ chips out there - I suspect most of the working systems using MySensors in fact are using clones with success. There is just a possibility of getting a bad batch, with a poorly functioning clone that doesn't work well enough. And we're working on how to test for that - either by testing the module (registers, power usage) or just by doing packet loss tests.

Some of the variants may actually work better than the genuine nRF24L01+ chips, for some purposes.

I'm still attracted to the nRF24L01+ style transceivers because I also use them for applications that do need the higher bandwidth and/or longer transmissions. There are stricter limitations on 433/868/915 MHz than on 2.4 GHz, in part because the lower bands have less total bandwidth to share, and in part because they carry further (ie: cause interference at longer range). But for a sensor net only, with occasional short bursts of a small amount of data, the RFM69 and other subGHz transceivers could be ideal.

I think the Moteino and Anarduino platforms look very good (I only have the latter and have not gotten around to testing them). The other option that comes to mind is the JeeNode, which originally used the RFM12b but has been upgraded to work with the RFM69CW.

Also, if you haven't checked out Jee Labs, do - his blog posts over the years have been an invaluable source of information on low power sensors nodes and related electronics. http://jeelabs.org - you can find links from there to the JeeNode store as well. In the US they are sold by Modern Devices.

It looks like it's just an ultrasonic transducer.

With multiple ultrasonic transducers one could create a wind speed and direction sensor. (If you measure N/S wind speed and E/W wind speed you can get total wind speed and direction).

The typical cheap distance measuring modules use very cheap 40KHz transducers; these operate at 200 KHz.

Wind speed can be measured by timing a pulse between two transducers. The pulse will arrive slightly sooner if the wind is blowing towards the receiver, slightly later if it's blowing the other way, but the differences are small so you have to compensate for other factors like temperature, perhaps air pressure and humidity.

With 4 transducers at over $200 even before all your analog circuitry to generate the high voltage drive and sensitive receiver, this is not going to be super cheap!

Agreed. If the module takes more power during transmit because it's putting out more RF, we might be able to back it off by using less than the maximum power settings, or use it in applications where it more rarely transmits.

But if it uses too much sleep current, it's a bad option for battery power.

@Stric said:

Using a non-scientific method; looking at the angle of battery discharge graphs over a week, I've noticed that the modules I got from ITEAD are draining batteries at about half the rate compared to an unknown (but probably fake) pretty good module.
ITEAD module; slightly under 1% per day
"other modules"; about 2% per day
This is when measuring and transmitting DHT21 data every minute.

Good information. Hopefully, the scope will help sort out whether that faster drain is mostly during transmit/receive activity, or mostly during the idle time, or both.

I don't really know what a good value would be. Since it's across a 1 ohm resistor (in one case), and you probably want an RC time in the vicinity of microseconds, I'd start with around 1 uF and move up or down from there based on the scope trace. You may be able to just clamp the (short) leads of a cap to your probes to get a look, before soldering.

And I'll be interested in what other tips you collect that are useful.

@NeverDie said:

@Zeph: I'll may attempt those things tonight, though I'll be giving priority to moving over to TBRH20 first, as it will be better for comparisons if we minimize platform differences, as well as run the same library.

I agree that using the same library is good for cross comparison among multiple experimenters.

However, if it turns out that the power profile differs between libraries, on the same hardware sending the same packet, that would be worth some investigation as well to understand why (and perhaps learn how to optimize power). Yeah, that's a different question than detecting variants and understanding their advantages/disadvantages, but the same measurement hardware can be used.

I was wondering if a small cap across your sense resistor might smooth the traces a bit, and still tell us what we want to know - which is about average power, on a multi-microsecond timescale.

• It is possible to detect when an ACK is received? (RFToy or MySensor libraries)

When ACK/autoretry (ESB mode) is enabled, the transmit is not indicated as complete until an ACK is received or all retries are exhausted.

• The measure of the RTT (Round trip time), by it's definition if the ACK messages are used the RTT should be the time difference between the first bit of the message sent and the first bit of the received ACK message

People could define RTT in several ways for different purposes. You describe one way one could define it. For the most part tho people are going to measure the times between two events that are visible in the chip registers. So if you want the RTT for a message with an ACK (and no retries), you might measure the time from when the transmit is triggered, to the time that the chip considered it complete (ack received), which will be shortly after the last bit of the ACK is processed.

Another way to define RTT would involve a software ACK at a higher network level being received - master uC sends to slave uC, slave parses and sends a new packet to the master uC. Again, it's going to tend to be measured via the visible registered (from transmit fired to packet received).

• The payload used being the max allowed of 32bit for one packet, does it not overflow? does this cause problems? (need to test)

The nRF24L01+ has a maximum payload of 32 bytes (a protocol layered on top of that, like MySensors, may have it's own smaller maximum payload at that level, after its own protocol overhead). Not sure what you are asking but maybe NeverDie will.

• Is there a way to be sure that there is enough time for the receiver node to switch between modes (receiving/transmitting)?

If you are using hardware ACK, that switchover (primary transmitter into receive mode temporarily for receiving the ACK, primary receiver into transmit mode temporarily for sending the ack) is handled automatically, including the 130 uS or so needed to switch the radio. If you are using a software ACK, you would need appropriate delays and/or timeouts.

You might also see if the second register bank can be selected (ACTIVATE+0x53) and read. See http://sigrok.org/wiki/Protocol_decoder:Nrf24l01#Variants_and_clones_of_the_chip from the penultimate link on the fakes thread.

If it has a second register bank then it's probably a BK24* series or a clone/derivative thereof. (Note that the contents of that second bank seem to be undocumented, at least in English). This niche is apparently popular enough that there are second level derivatives - for example advertised as being BK24* compatible which is in turn nRF24 compatible with extensions!

I did catch a reference somewhere that implied there was a real RSSI in the second register bank in some derivative; that could be handy if true.

There's a reference at that same link to the Nordic nRF24L01 (no plus) needing an ACTIVATE+0x73 command to enable certain features that are automatically available in the nRF24l01+.

This is not something I am aware of. I wonder if some features like ESB can be enabled on the non-plus version? Anyway, if so, this might also be a test which helps sort out clones - if they look like a non-plus derivative, do they respond to ACTIVATE+0x73? (the linked source does not suggest that 250 Kbps mode is one of the features which could be activated)

Suggestion: for the clone/fake chips, could you test whether they have the SI24R01 power control?

That is, set bit 1 of register 6 and see if they draw even more current. That should set the SI24R01 - or perhaps a derivative or clone of it - from 2-3 dBm to 7 dBm, which will probably mean using more supply current when the bit is 1 than when it's 0.

See the (currently) last couple of links in the OP of the fakes thread.

@NeverDie said:

It turns out my scope can do better than I thought. Here's the blob module again, but this time at 5mv/div.

How did you reduce the noise so much in your later scope captures?

We would expect the data transmission per se to include a fixed prefix byte, 5 bytes of address, 9 bits of control, 4 bytes of payload, and 2 bytes of CRC (I think). 105 bits = 105uS. (I'm not sure where the 14 bytes in the calculation @Yveaux presented comes from. Either the nRF sends a 16 bit control but only documents 9 bits of it, or the nRF actually sends 9 bits but some software translates the 9th bit into a second byte for analysis purposes)

Before that there's something like 130 uS to power up and stabilize. And there could be additional time gaps before or after the data per se.

And of course before all that, there is the time to load the data and commands via SPI; power might potentially rise during that, I suppose.

Only the time to load commands and data would seem to care whether the uC is running at 8 or 16 MHz. The 105 uS data time should be the same, if they are OTA compatible. The 130 uS power up and stabilizing time could vary between chip designs.

Any way to see if the fake chip is one of those transmitting with more RF power output? (If it wastes more power doing the same job, not good. If it has the ability to run at higher power but can also be reduced to sip more carefully, that could be a win).

I look forward to your further testing. Maybe worth checking how much supply current is saved in the other transmit power settings.

@NeverDie
http://tmrh20.github.io/RF24/classRF24.html#aa0a51923a09ba4f3478aba9be0f8a6a1

You are going to need your Davy Jones uCurrent to measure sleeping current!

@NeverDie said:

@Zeph said:

@NeverDie

So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.

They are sounding potentially attractive. Here is some of what I am wondering.

1. Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)

2. Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?

3. Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).

It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.

Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.

@Zeph: Regarding #2: What is ESB mode?

Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.

@hek is ESB mode still used in MySensors?

So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.

Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?

Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!

Until a new blob module type shows up.

Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.

People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.

BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.

I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.

Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.

I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.

If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.

Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24

Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.

Hm, I just found a reference regarding the CH340 and 3.3v. From http://www.minikits.com.au/nano-v3.0b

The Arduino Nano can be powered via the Mini-B USB connection,  6-20V unregulated
external power supply (pin 30), or 5V regulated external power  supply (pin 27). The 
power source is automatically selected to the highest voltage source.

The CH340G chip on the Nano is only powered if the board is being powered  over USB. As a result,
when running on external (non-USB) power, the 3.3V output  (which is supplied by the CH340 chip)
is not available and the RX and TX LEDs  will flicker if digital pins 0 or 1 are high.

My question about using the 3.3v supply from the Nano for the nRF came from two use cases:
Running with a 5v USB power supply sounds OK. But I was also thinking of running from a 12V supply in a case where 12V is used for relays and lights anyway. I was thinking to use the onboard 5V regulator for the Nano's uC, and the 3.3v supply for the radio. The quote sounds like the latter would not work - unless perhaps I bridged the 5V from the uC regulator to the USB 5v pin to activate the CH340 ? (Some more power, perhaps interference if I wanted to use the uC RX pin).

Any knowledge or experience to share?

One aside: Sometimes a regulator is spec'd up to 12v and sometimes a 12v supply is a little high. My thought was to insert a diode in line to drop a volt or so; this should give more margin, and also at least slightly reduce how much of the voltage/power has to be dropped & dissipated inside the linear regulator. As a side effect, it might help with accidental reversal of voltage. This is also my answer to someone who wanted to run an unregulated ardu pro mini off 4xAA alkaline.

@Fabien posted something of interst to me a week ago:

With UNO I have more lost packets without extra capacitor. I think 3.3V output is not enough good. With Arduino Nano, it's ok

So far I've not tried using the Nano's 3.3v supply for the nRF24L01+; as I understand it, the 3.3v supply was a side effect of the FTDI USB to serial chip, and I wasn't sure of its quality.

But if it works, I might use the Nano for some nodes. In particular where I need to run the uC at 5V for sensors or pixel LEDs, but the radio at 3.3v, it would save some space and wiring.

Do people have good experiences running the non-amplified nRF from the Nano's 3.3v supply? Has it worked with nano clones (I think some have replaced the FTDI with a CH340 chip)?

@NeverDie

So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.

They are sounding potentially attractive. Here is some of what I am wondering.

1. Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)

2. Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?

3. Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).

It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.

Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.

The RFM69x operates in one of three smaller frequency bands (ie: fewer available frequencies): 433MHz, 868 MHz (Europe), 915 MHz (US).

While there are supposed to be scores of independent channels for the nRF24 on the wider 2.4GHz band, there isn't as much room on the lower frequency bands. So 300 KBps is more of a theoretical limit; mostly the RFM69 is used for lower bit rates than that, with correspondingly lower bandwidth - and thus higher range! Unlike the nRF, you can trade off bit rate & bandwidth vs range (at any given power).

For most sensor networks, I think the RFM69 will have plenty of data bandwidth and better range (at say 56Kbps or so). For a good example, see the JeeNodes (which used the RFM12B but are migrating to the RFM69x which fits the same niche but is a better chip). JeeNodes fit a niche very similar to MySensors in that there are distributed sensor nodes communicating with a central hub, with some of the sensor nodes sleeping most of the time to save battery power. (JeeNodes are not as well integrated into common Home Automation systems, but we are now talking more about hardware and protocols).

I also use the nRF for holiday lighting control, which is more bandwidth hungry. For that the higher speeds are required. In this case a master is blasting data as fast as it can to one or more slaves; the slaves don't need to respond much, and if they do they can be polled with the Master so the master doesn't broadcast at the same time. (If using nRF for MySensors too, obviously they need to be on different channels).

There is some usefulness to me in using nRF24L01+ for both, so the same node hardware can potentially be re-purposed; it's only a firmware (and channel) change to switch between these networks. But I'm rethinking this and wondering about switching sensors to the RFM68x.

I'm not sure about power efficiency. An analysis will depend on how often the node needs to be powered up and for how long, as well as the sleep current. JeeNodes are also pretty careful about power.

@NeverDie So you've received two orders of blob modules which work well, from different sources?

Where did you order them from? I'm interested.

The packet loss info could be useful.

The Round Trip Time (RTT) testing would seem to make sense only if using ESB with ack and auto-retry is enabled, and there are errors which require one or more retries. Without retry, the packet should either be received in a fixed amount of time, or not received; the nRF24L01+ doesn't "think it over" for a while before deciding on weak packets. So it's just a disguised packet loss test, but harder to interpret.

If we want to test link quality, I think packet loss without retries is a the measurement.

And there should often be different packet losses with short and long packets. Long packets are more likely to get corrupted and lost (failing the CRC test).

Wow, what a mess to sort out.

A given module may have

• genuine Nordic nRF24L01+
• genuine Nordic nRF24L01 (no ESB, no 250Kbps) - possibly marked as +
• quality clone of either, possibly even out-performing Nordic in some way
  (some have higher RF power output)
• clone with inverted OTA ack bit (ESB OK between same, incompatible with Nordic)
• clone with reduced sensitivity and/or increased power usage
• any of the above with missing passive components compared to Nordic reference design

Meanwhile:

• We cannot count on visual inspection (Nordic is fabless, some genuine chips may differ over time) or date codes.
• We do not know of register tests to distinguish differences (except L01 vs L01+)
• The inverted NoAck bit could be easily tested OTA using ESB mode to a known-good module.

The packet loss testing may have value, but it can be tricky. NeverDie says " The modules seem more finicky about their orientation than others that I've tested, and moving things just a little can make for much, much worse results."

That makes comparison difficult - is a given module better/worse than another, or was it it moved "just a little"? There's also the issue of intermittant interference in a crowded band.

The idea of having "screwed down" test positions as someone suggested is making a lot of sense. Maybe.

I'm wondering about the blobs that worked better than genuine/iTead nRF24L01+ (@1Mhz), is that because they are the higher powered clones? What's the power supply drain during transmit, compared to genuine?

The RFM69 family is a good alternative for most sensors, where lower data rates and (regulatory) lower duty cycles of 433/868/915 MHz bands are usually OK. If we want the higher data rates of GFSK at 2.4GHz, maybe the RFM73 is more consistent (fewer if any clones)?

@mainali said:

I am a victim of those fake clones.

Well said. We've grown used to the quality clones, now there are "fake" clones on the market.

Sort of like cheap cheeses. In the US there used to be "natural" cheese, and "pasturized process" cheese (like "American cheese", a sad thing to have named after your nation). Then there was a brand of semi-soft block cheese called "Velveeta" which was labeled as "pasturized process cheese food". And some off-brand variants of that were labeled "imitation pasturized process cheese food". (These were all legal distinctions based on US Gov't standards, and the terminology has since changed).

So our nRF modules started out at "pasturized process cheese", and now there's "imitation pasturized process cheese food" entering the market - without such honest labeling.

Yes, some might be clones of the nRF24L01 (no +). Others have bugs.

And at least some modules with epoxy blobs rather than chips may also be missing some of the normal external passive components leading to reduced performance - in addition to questionable chips per se. This is almost worse for our sanity - being flakey rather than outright failing some digital aspect (like ESB) 100% of the time.

One commenter in one of the above referenced threads mentioned having one module which seemed unusually tolerant of the power supply quality - which he believed was a genuine Nordic chip. Maybe the PS issues we've all adapted to are largely due to our using clones (even the relatively good clones).

The other thing we might do is get into the habit of immediately quality testing new batches of nRF24L01+ modules.

First thing is just to see if it works in ESB mode with our existing chips, and that it works on all channels (some clones are reported to be marginal at the ends of the band).

I wonder how else to test RF quality. Maybe have a standard test location - like test it from a particular place in the garage against a known existing node, where we know that our old nodes would work but maybe barely. If the new batch fails from that location, we won't waste too much time with weak chips confusing our debugging in the middle of a more complex project.

(see new links at end of this post)

(see earlier thread about nRF24l01(no plus) substitutes - not quite the same topic as this thread but related; from a comment below)

(see newer thread on finding the best nRF24L01+)

First off, it appears that most of the cheap nRF's have been fakes (not genuine Nordic chips). There is some indication that they may use somewhat more power and be somewhat less sensitive, than the real thing - and may be more sensitive to power supplies. Not a big problem, since that level of performance is what we're used to (many of us have probably never used a Nordic nRF24L01+).

However, there are even cheaper fakes hitting the market, with inferior specs and outright incompatibilities. In particular, the Si24R1 got the ACK bit inverted (following an error in the datasheet), so it's incompatible with the real nRF24L01+ (and good clones) in ESB mode. (The Si24R1 is often falsely labeled as nRF24L01+). In some cases you can build a network of such variants that work OK together, but a node with the other chip won't work right (at least in ESB mode). There are several other clones too, with whatever changes they happen to have.

And clone chips weren't enough, there is a new cheap module with the chip under an epoxy blob (no biggee per se), which also omits a number of the passive components in the Nordic reference design used by most modules (caps, resistors, inductors). This seems to have problems with the ACK bit due to the chip itself (see avove), but due to module design also probably has reduced actual transmit power, less power filtering, etc. (And would even if it had a good chip in it).

I'm mentioning this because chips that don't work right in some circumstances (depending on which features are used), or which are electrically marginal and thus have intermittent problems, can lead to serious hair loss. And this is probably going to be an increasing problem in our niche, as our vendors switch to the cheapest suppliers.

If you are having odd problems, sometimes it may be that you have one of the clone chips or cost reduced modules.

Perhaps we need to find a good supplier who knows we want only "genuine" high quality clones and who will not suddenly switch to less compatible ones. In the DIY christmas lighting community many people patronize one particular Ali Express vendor (Ray Wu) who has an overall good reputation within that community, who is aware that many people in that community communicate frequently, and who wants to keep a good reputation. He gets enough volume from that community to have incentive to keep up his quality and to fix problems (at least in relative terms among Ali Express vendors).

Some background:

http://hackaday.com/2015/02/23/nordic-nrf24l01-real-vs-fake/

http://ncrmnt.org/wp/2015/03/13/how-do-i-cost-optimize-nrf24l01/

Updates:

List of related chips (if not mislabeled as Nordic these would be clones, derivatives or compatibles, not fakes per se, but I'll list them here as some fakes may really be one of these chips or closer to it): http://sigrok.org/wiki/Protocol_decoder:Nrf24l01

Info about Si24R01 and power: https://github.com/solarkennedy/equail/tree/master/Libraries/RF24

@m26872 As I said in the first post, if you measure against the internal 1.1v reference (rather than the more common Vcc), it can work. And I see that's in fact what you are doing, so no problem, carry on.

@phil83 said:

@Zeph I wanted to use the internal reference as described here: http://www.mysensors.org/build/battery

The voltage divider in that circuit diagram is for measuring an input voltage (into the regulator) higher than Vcc (out of the regulator). Bad idea without a voltage divider. Since you are instead using an up-converter and Vin < Vcc, I think you can do without the voltage divider resistors.

As an example, suppose you used one cell at 1.5v draining to 1.ov. With a Vcc of 3.3v a direct reading would give ADC readings of 465 falling to 310. Using that voltage divider would yield 149 falling to 99. (all out of 0 to 1023). You just lose resolution by inserting the divider. (WIth two cells double these numbers).

The caveat is that I'm uncertain about is startup transients - with Vin applied to the pin before Vcc stabilizes. Not sure if that's a real problem or not, tho - maybe somebody else would have thoughts.

Just curious - if Vin < VCC, why are you using a voltage divider to get the battery voltage? If you are using VCC as the ADC reference, you should be good without a divider, I'd think.

It would be possible to use the 1.1v internal reference (ONLY when measuring battery, not most sensors), in which case your divider could make sense, and that would remove the stability of the VCC power supply from the measurement - tho I rarely see that approach taken.

Has it been determined that the messages are getting to the gateway's radio (transmitter)? If so, then caps on the nRF24L01's power supply may indeed help if power sag is the issue; if not, then we're looking in the wrong place and some of the other suggestions may be relevant.

IF it's about power sag in the radio, that may require large caps. Sometimes small caps help the radio, if it's having problems with high frequency spikes and noise in the power supply. But if the problem occurs over hundreds of uSec (one packet affecting the following one) then it would be very low frequency and relatively long duration.

However, a better power supply would be a better solution if so. A scope (even an arduino based software scope given the frequencies involved) might help determine if the supply is really the problem.

AND of course, the first question is whether the controller firmware is even TRYING to send every packet, as this post began.

Have you noticed any range reduction or orientation sensitivity from putting the antenna over a PCB plane?

Hmmm.. If somebody is taking security this seriously, they might want to use a different chip (or use the whitening technique referenced in an early post in this thread): http://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Skip back and forth in the thread.

One odd effect of using a widely used professional chip is that in some scenarios it can make one less secure - because now you are using something which has a far higher target profile than MySensors. Put another way, the MySensors community is a small enough movement that it's not worth a lot of resources to attack it; but the widely used chip IS an attractive target, and a discovered security hole might pull in MyS "for free". Not a problem if it has no vulnerabilities of course.

Notice Bill's concern that there may be a deliberate back door in the chip. A few years ago that might seem paranoid; by now we know that it would be unusual if certain security agencies had NOT at least considered working out a special deal with the manufacturer of a widely used chip.

Wouldn't it be interesting if the software implementation was, in some areas, more secure than the hardware?