#76 ChipCon doesn't work properly if battery powered

[Anonymous]

We did observe the following:

* B-MAC on USB powered nodes works quite ok (could be
better but ok).

* B-MAC on Battery powered nodes hardly works at all.
Some packets might be received but surely below 10%

* Disabling Low-Power Listening on didn't help

* The CC1000-test.c in app/bttest which provides a
rudimentary MAC layer/protocol which performs very
well, both USB powered and Battery powered.

The problem can be tracked down to the reception of
packets beeing problematic. Sending is always fine
(tested with USB powered receivers).

Because of cc1000-test working fine, a direct hardware
issue can be ruled out. Still, it is unclear what's
causing this problem.

Bug #1487477 (cc1000_set doesn't work in 1.6) might or
might not be related to this.

[Nobody/Anonymous]

Logged In: NO

Submitted by me (Matthias Ringwal/freckle)

[Matthias Ringwald]

Logged In: YES
user_id=687107

more tests with cc1000-test.c:

the interrupt-driven mac implementation runs fine. we also
added a printf inside the spi handler which still works fine.

an even simpler test, which polls the spi data register and
prints it show bit-errors. Here we observed, that if we
first stored a received byte in a buffer and dumping the
whole one had less errors than printing every received data
immediately.

So to me, it looks like it matters what the AVR does
in-between the received bytes, a wild guess might also if
external memory is accessed.. I will try next to test a)
different Sleep Modes, b) busy waiting for the packet and c)
have a second worker thread.

[Matthias Ringwald]

Logged In: YES
user_id=687107

we conducted the following tests:
* quick glance at pins on oscilloscope didn't reaveal
anything
* via CCC-Interface:
* B-MAC ping/pong test: USB powered ok
* B-MAC ping/pong test: battery powered not ok
* no difference if LPL off/on
* with the simple mac protocol in app/bt-test/cc1000-test.c
* interrupt-driven ping/pong battery powered ok
* interrupt-driven ping/pong + dump packet in IRQ
handler powered ok
* byte-wise spi polling + dump => high bit error rate
* byte-wise spi polling + dump after packet => lower
bit error rate
*

preliminary conclusion:
* chipcon communication is possible with battery
* we experienced no lost bytes but bit-errors
* we experienced no bit-errors using USB power
* it matters what the atmel is doing during waiting for
the next received byte

wild guesses:
* the sleep mode caused during the IRQ-driven
implemenation helps
* using external SRAM might be relevant

[Matthias Ringwald]

Logged In: YES
user_id=687107
Originator: NO

new tests are quite different then the last ones.

ChipCon works from VCC_IN almost as good as with USB power.
Kay suggested that the USB cable might actually be work as
a kind of antenna.

For ChipCon without BT, setting the nut/os sleep mode to NONE
helped for the EWSN SNIF Demo.

[Matthias Ringwald]

Logged In: YES
user_id=687107
Originator: NO

using those lines:

// INSOMNIA! sleep mode causes chipcon reception to collapse
NutThreadSetSleepMode(SLEEP_MODE_NONE);

a simple B-MAC routing works.

This is not enough to run Chipcon and Bluetooth in parallel. There an exta 4.5 V battery at VCC_IN help.