Computing stuff tied to the physical world

JeeNode Micro breakout

In AVR, Hardware on Mar 24, 2013 at 00:01

While messing around with a bunch of JeeNode Micro’s here, I decided to create a little convenience breakout board for it:


Sooo many ways to mess up – it definitely helps to avoid silly mistakes! This particular board doesn’t do that much, but it’s still a nice convenience when you’re drowning in cables and trying to debug some of the nastier bits, such as the Flash Board ISP programmer:


The above setup was the result of what turned out to be a wild goose chase – stay tuned…

  1. Not too relevant with the post and I can’t remember reading about it, but I was wondering whether the JeeNode μicro tests for min power consumption were conducted using 0dB or -17.5dB transmitter output attenuation. Maybe, if the receiver is not too far from the JPμ one could reduce the JPμ’s transmitter power and achieve even greater savings.

    • I’ve always used the default until now. There’s definitely room for optimisation there, IMO.

  2. @dzach, at first glance, it could be a driver function to back off on transmit power to achieve a target BER when it is a simple pairing of Nodes. I think your nRfMon practical results show that this is not any easy extension to implement – there is probably not a static optimum power level due to the variability of the background level and/or specific interferers.

    Perhaps a user-level implementation is practical when ACK’s are enabled, down shifting power level within a restricted range on each successful handshake, and then recovering with up shift(s) on failure. It won’t be stable, but on balance the energy saved from many down-shifted transmits might well outweigh the extra transmits needed to recover the link. A much more elaborate method is used in cellphones – but they have the code space and plenty of extra protocol to deal with this effectively.

  3. That’s very interesting, martynj. One might establish a low BER/high power link initially and proceed as you describe; later, an increase to that BER could be interpreted as lack of adequate S/N margin and could eventually lead to increase the output power to compensate. Calculating PER instead of BER is trivial and low cost and may be a lot more practical to implement and test.

    I think the new JeeLib has facilities for measuring RSSI while receiving packets. This may make the decision to increase or not the xmit power more “educated” and the process more stable, since a high RSSI may indicate that the cause of increased BER might not have been lack of signal strength but something else.

    That whole process presents a closed loop control, with feedback over the airwaves. The transfer function may include BER/PER, RSSI and perhaps other parameters like packet length etc. Good food for thought.

Comments are closed.