Implementation Issues

1. Watch dog Timer

BTLE transactions Tx/Rx have no time constraints, hence, it will get stuck to a channel without hopping if nothing is received.

Solution: isItTime(uint32_t clkAtStart, uint32_t millis) function as a watchdog timer in the firmware cc2400 sensing function.

2. Channel Switching

Ubertooth firmware turned out not to switch between channels. It only display's the channel change on the UI, but physically it is fixed on channel 37 (2402MHz).

The problem was in switching the BLE Adv Channels at runtime. Any attempts brought the ubertooth to a halt.

Solution:

1. Modify the ubertooth_rssi condition "if ( channel < 2402 || channel < 2480 )" to "if ( channel < 2402 || channel > 2480 )"
2. Introduce new hoping mode in 'hop():bluetooth_rxtx' to handle the specific hopping on Adv channels.
3. retune the radio with 'channel-1' using 'cc2400_set(FSDIV, channel - 1)' then set the threshold 'cs_threshold_calc_and_set(channel);' after locking the cs2400 from any modification attempts
4. release the lock.

3. Messages to Host

Options: 1- break execution and return to host whenever a message needs to be displayed, then move back to the firmware to complete execution. Imposes large latency 2- Encode the message to be displayed in a packet and enqueue it under a new type, then decode it at the host side. This solution avoids multiple context switching between host/firmware to fulfill the standard requirement in informing the users of current states.

4. CONNECT_REQ packet scrambled at receiver side

• At the receiver side, the packet is scrambled starting from the last 2B of the 2nd Adr.
• Turns out that on any packet after 12B of the Advertising payload the packets are scrambled.
• The exact same bit scrambling is seen on the ElliSys sniffer.
• I printed the packet right before the "le_transmit_boss" function and it was correct.
• Conclusion: The transmission needs to be reviewed, either the whitening or packet sending.