Skip to content
This repository has been archived by the owner on May 18, 2022. It is now read-only.

Design a better hardware/radio interface #48

Open
jonas-schievink opened this issue Apr 21, 2019 · 5 comments
Open

Design a better hardware/radio interface #48

jonas-schievink opened this issue Apr 21, 2019 · 5 comments
Labels
area: hal Code Area: Radio hardware interfacing code status: needs design Needs design work (API, communication between components, etc.) type: enhancement A new feature or an improvement for an existing one

Comments

@jonas-schievink
Copy link
Owner

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 and transmit_data methods on the Transmitter trait behave very differently since transmit_data also ensures T_IFS is respected. This isn't really wrong, but it should also be done by transmit_advertising, except when we're just a beacon. The solution for this, I think, is to split the Transmitter trait into "beacon-only" and "connection" functionality:

  • Beacon-only use requires being able to do single-shot transmission and reception on the advertising channels (eg. no TX->RX sequence that respects T_IFS). It's very simple to implement.
  • Connections require only TX->RX sequences that respect 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 proper LinkLayer, and doesn't allow plugging in a BeaconScanner. 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 of PacketSink trait?) that makes this easier.

@jonas-schievink jonas-schievink added type: enhancement A new feature or an improvement for an existing one status: needs design Needs design work (API, communication between components, etc.) area: hal Code Area: Radio hardware interfacing code labels Apr 21, 2019
@jonas-schievink jonas-schievink added this to the Oxidize milestone Apr 21, 2019
@jonas-schievink jonas-schievink removed this from the Oxidize milestone Apr 30, 2019
@ryankurte
Copy link

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.

@jonas-schievink
Copy link
Owner Author

@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.

@ryankurte
Copy link

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've been using the DLP-RFS1280 modules, which are still not cheap but workable for prototyping.

It does seem to be lower-level than what we're looking for here, but could still be helpful nonetheless.

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 Receiver trait too i'll have a go at implementing it on these ^_^

@ryankurte
Copy link

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 ^_^

@eldruin
Copy link

eldruin commented Jun 15, 2019

You can also get one of these modules for 7-10 USD.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: hal Code Area: Radio hardware interfacing code status: needs design Needs design work (API, communication between components, etc.) type: enhancement A new feature or an improvement for an existing one
Projects
None yet
Development

No branches or pull requests

3 participants