I’m looking at using the RuuviTag in a bluetooth project that sends sensor data using only advertising packets. I’ve had a quick look around the the ruuvi/ruuvi.firmware.c source and I can see that this appears to use bluetooth 4 based advertising packets - I’m no bluetooth expet so I could be wrong.
My question is, I’ve seen it written that the RuuviTag is “Bluetooth 5 ready” Does that mean the current implementation of the stack supports bluetooth 5, or that the hardware supports it but is waiting for the stack to be updated?
If I wanted to use the larger advertising packets possible with Bluetooth 5, and possible Aux advertising packets, would I need to interface directly with the Nordic SDK? Or have I just missed something with the current Ruuvi Stack?
Yes, you’ll need to interface directly with the Nordic SDK. I’m working right now on BLE advertising code anyway, I can take a look at what would be required to support extended advertisements while I’m at it.
Some BT5 features are supported, GATT connection accepts switch to 2MBit/s modulation and long range advertisements are used with nRF52811 on some firmware versions. However, extended length advertisements or 2 MBit/s modulation on advertisements aren’t used by any Ruuvi Firmware I’ve worked on.
Can you give me some feedback on my idea on Ruuvi BLE interface update? I was thinking that radio initialization defines the modulation for all further operation, and advertising and GATT modules check what is the expected modulation and try to maximize the MTUs if 2MBIT/s is selected.
Right now maximum payload in ri_message_t is 24 bytes, which comes from maximum manufacturer data advertisement payload length, not counting the header or manufacturer ID. If extended advertising is enabled at compile time, I’d switch the message length to 248 bytes which is the maximum payload in GATT tx.
Usage would be
// Setup data
ri_comm_channel_t advertisement_channel;
ri_comm_message_t msg = {0};
memcpy(msg.data, p_data_to_send, size_of_data_to_send);
msg.data_length = size_of_data_to_send; //!< maximum length 24 or 248 depending on config.
msg.repeat_count = 1; //!< Send exactly once
// Initialize
ri_radio_init(RI_RADIO_BLE_2MBITS);
rt_adv_init(&advertisement_settingsl); //!< power, interval, manufacturer ID, channels etc.
rt_adv_set_on_sent_isr( my_adv_sent_handler); //!< Function pointer, called on data sent.
// Send
rt_adv_send_data(&msg); //!< Queue data to be sent. Asynchronous.
// Volatile bool flag, set by my_adv_sent_handler once sent.
while(!m_adv_sent)
{
ri_yield(); //!< Sleep until data is sent
}
The result would be that advertisement at primary PHY at 1 MBit / s would be minimum allowed length and secondary PHY at 2 MBIT / s would contain the necessary headers + the actual payload in manufacturer specific field.
I’m not yet sure if this actually can be implemented exactly like this, and I’m unsure what kind of headers secondary PHY requires but the goal would be to hide those details from the user.