-
Notifications
You must be signed in to change notification settings - Fork 56
Design a better hardware/radio interface #48
Comments
ooh, interesting problem ^_^ i don't have enough of a grasp of BLE to make suggestions atm, but i do have another compatible radio-sx128x i'd be interested in implementing against and some experiments with radio interfaces if those are useful references. |
@ryankurte That's a very interesting chip! I was looking for something like it. Can you recommend a board that uses it (preferably one that doesn't cost 450€)? I'll also keep an eye on your radio crate. It does seem to be lower-level than what we're looking for here, but could still be helpful nonetheless. |
i've been using the DLP-RFS1280 modules, which are still not cheap but workable for prototyping.
yeah it might well be too low level, i'm planning to push that up a bit with nb implementations next i have the time, but, definitely interesting to see what works for BLE. when y'all have a |
the radio hal is also v much an experiment atm, because i've suffered through too many frustratingly implemented radio drivers in the past, so i'm totally up for modifying it to suit if it's reasonable to do so ^_^ |
You can also get one of these modules for 7-10 USD. |
The current interface relies on undocumented assumptions and isn't very clean. It should be fixed before we start supporting more MCUs to avoid introducing too much technical debt.
(the timer interface is basically fine at this point, this issue is about the radio interface)
For example, the
transmit_advertising
andtransmit_data
methods on theTransmitter
trait behave very differently sincetransmit_data
also ensuresT_IFS
is respected. This isn't really wrong, but it should also be done bytransmit_advertising
, except when we're just a beacon. The solution for this, I think, is to split theTransmitter
trait into "beacon-only" and "connection" functionality:T_IFS
). It's very simple to implement.T_IFS
, on both advertising and data channels. It is more difficult to implement.Another problem @Chocol4te has faced is that the current
BleRadio
implementation for the nRF52810 only works with a properLinkLayer
, and doesn't allow plugging in aBeaconScanner
. This is ultimately an interface decision made by the device crate, but maybe we can find a solution in Rubble itself (perhaps via some sort ofPacketSink
trait?) that makes this easier.The text was updated successfully, but these errors were encountered: