SW-19. BLE TX feature

[tryuan99]

This code contains the ble.h header file, which allows SCuM to transmit BLE. It also contains code for the LC calibration using the optical programmer.

The application file ble_tx_154_rx allows SCuM to receive 15.4 packets from OpenMote and broadcast the data as BLE packets.

The code was refactored into the current structure and works with the ble_tx.c and ble_tx_154_rx.c application.

• Call ble_init_tx() after initialize_mote().
• For a test packet, call ble_gen_test_packet() before calling ble_transmit(). Make sure to set the frequency with LC_FREQCHANGE before transmitting.
• For a custom packet, set the corresponding fields first like name, temperature, etc. Call [field]_tx_en(true) to include them in the packet. Finally call ble_gen_packet() to generate the BLE packet and then call ble_transmit() to transmit the packet.

[changtengfei]

@tryuan99 here are two questions:

1. does the bin and hex images required to be committed?
2. how do you test your code work?

[tryuan99]

@changtengfei

1. I removed the bin and hex images in this commit: 39daf94. Thanks!
2. To test ble_tx.c, I ran the code on dev board Q4 and tested that I could receive SCUM3 packets on my phone. I also tested the BLE packet generation by injecting dummy data in the packet and verifying the packet contents on my phone. Sweeping was checked using the spectrum analyzer.
   To test ble_tx_154_rx.c, I had an OpenMote transmitting on channel 11 nearby sending a simple counter. I logged over UART whether I was receiving any packets. I then verified on my phone (see my SCuM meeting presentation on 2020-02-19) that the BLE packet contained the 15.4 packet contents, where the first four bytes are 0xXX 0x01 0x02 0x03.

[changtengfei]

@tryuan99 great! what's the app on the phone I should install for the test?

[tryuan99]

I use https://github.com/tryuan99/android-ble-scum, which is an Android app I wrote that specifically filters for SCuM's BLE packets and displays all of its contents. For general BLE packets, I use nRF Connect to sniff the BLE packets.

[changtengfei]

@tryuan99 could you generate an apk file and attach/release it in your repo? So the other can just download it.

[changtengfei]

@tryuan99 I have reviewed your PR. Usually you are not suppose to touch the bsp/driver code, such as the optical/radio, unless your are sure the changes won't break the other projects.

For the PR, the changes in optical will break all the existing projects.

To fulfill what this PR is trying to do I would propose a way to do so.

Re-write the BLE tx app based on the frequency tx.

• In the frequency settings, you narrow down the setting range to somewhere you are sure the correct frequency is located at. In another word, you only sweep that short range of frequency settings.
• send a packet or two at each frequency setting, in the payload, put the frequency setting you used for each packet
• check on the bluetooth app side, to see the packet shows up, and you will know the right frequency settings for SCuM.

Try to send packet as short as you can, including the device name, frequency setting and any required field. So you can sweep the frequency setting range quickly to see packet show up in BLE app.

I think this will make the app simple and every time you run the code, you will always see packet in BLE app, even the frequency settings may various, but still in the range.

Does this sounds good for you?

[tryuan99]

@changtengfei My changes in optical.c should not affect other projects since all of the code I added will not run unless optical_enableLCCalibration() is called in the application file. The default for LC calibration enable is false.

I see that there is a change in radio.c that turns on the divider for radio_txEnable, which I manually changed in my code, so I will incorporate this change into my PR to not break other projects that do not require the divider.

[tryuan99]

I still need to test that this merge did not break my BLE code.

[changtengfei]

Oh I see there is a typo of this function that you fixed, I guess all other projects are using the wrong old name.

[tryuan99]

I fixed this in c5d0f48.

[changtengfei]

Great!

[changtengfei]

@tryuan99 there should be a conflict to the develop branch, as indicated in the jenkins builder but somehow the Github is not complaining.
Let me know if you have issue to fix it.

[changtengfei]

Could you confirm this will not effect the project using IEEE802.15.4 radio? such freq_sweep_tx/rx/lc_count?

[tryuan99]

I verified that freq_sweep_rx works, but I couldn't get freq_sweep_tx working, even if I check out the current version from the develop branch. After two fine code iterations, SCuM starts printing to UART.

[changtengfei]

Also here?

[changtengfei]

Hi @tryuan99 as the builder test still failed.

I reviewed your code again, there are only few comments left which I am not sure it is reason that test failed. Other than the few comments, the code looks fine for me. Could you take a look?

[changtengfei]

@tryuan99 I found the optical interrupts stopped at 24 times (expected 25), which is because of the large size of image takes long for CRC check. I have reported this in the mailinglist and the fix is in my quickCal PR: https://github.com/PisterLab/scum-test-code/pull/15/files, maybe we could try this PR again after merge mine?