• State Verified Answer
  • Replies 2 replies
  • Subscribers 70 subscribers
  • Views 433 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 310085
Options

Proper RF-protokoll and SOC selection for simple wireless sensor

JustSomeRandomDevoloper

Hello,

I am very much at the beginning of a development, I am sure that the nRF range from Nordic contains the right SOC but I am struggling with the large protocal and SOC selection.

The following constraints apply:

  • 1 server, 4 clients
  • Clients need to read the data of two identical I2C sensors. Both with fixed and identical address -> so I need two I2C busses
  • Each client shall transmit a data package of about 40bytes to the server. 
  • The transmit rate shall be between 1Hz and 0.2Hz 
  • The server shall be able to send data to all clients in order to e.g. change the transmit rate (or maybe with a mostly sleeping client that client could request an update and stay awake longer every now and then)
  • The client will be battery driven of a CR1220 coin cell and thus should sleep as much as possible, transmit quickly after wakeup and feature an low sleep current
  • Targetted run-time on this coin cell should be >= 2-3 days
  • Distance between server and its clients shall be between 0 and 5m in an open space. No walls in between.
  • The transferred data is not critical. So no advanced encription or pairing is required

Since I want to transfer the data between several identical SOCs, I don't care which protocol it is. BLE, Thread, Zigbee, ANT or Gazell. I could adapt to the most appropriate.

So I would be grateful for some opinions on a reasonable protocol at first. From this one can then probably select a SOC in connection with my very low performance requirements (except the two I2C busses).

Many thanks in advance... Marco

Parents
  • +1

    Hi,

    This sounds like a good match for BLE, using a star network with your clients as BLE peripherals and the server as a BLE central.

    With the Online Power Profiler for Bluetooth LE you can calculate power consumption for a given solution, e.g. an nRF52832 SoC in a connection as a peripheral with 40 bytes payload per connection event and connection interval of 1000 ms (one second) clocking in at expected average current consumption of 11 uA for the radio communication side of things. For a connection interval of 4000 ms (the maximum connection interval in BLE,) the expected average is down at 4.4 uA. Consumption related to the sensor itself and any application logic would come on top.

    Since you only need 5 m range with line-of-sight, you can probably reduce radio TX power as well, reducing power consumption further.

    Regards,
    Terje

Reply
  • +1

    Hi,

    This sounds like a good match for BLE, using a star network with your clients as BLE peripherals and the server as a BLE central.

    With the Online Power Profiler for Bluetooth LE you can calculate power consumption for a given solution, e.g. an nRF52832 SoC in a connection as a peripheral with 40 bytes payload per connection event and connection interval of 1000 ms (one second) clocking in at expected average current consumption of 11 uA for the radio communication side of things. For a connection interval of 4000 ms (the maximum connection interval in BLE,) the expected average is down at 4.4 uA. Consumption related to the sensor itself and any application logic would come on top.

    Since you only need 5 m range with line-of-sight, you can probably reduce radio TX power as well, reducing power consumption further.

    Regards,
    Terje

Children
  • 0 in reply to tesc

    He Terje,

    thanks for your input. BLE sounds OK to me. The online power profiler tool is pretty nice. It helps a lot to get an order of magnitude. I allready ordered a nRF52840 DK a few days ago and have a PPK2 laying around. So I guess I have at least the right hardware to start working. 

    My sensors will draw about 5mA each when running. Luckily, they have a OK power-up-time of 3ms. So I plan to actively control the GND line to the sensor in order to switch it off when the µC is sleeping. This will extend the uptime to 7-8ms but I guess this is still OK. I calculated about 30 days battery live for this combination of sensors an µC and this is more than enough. 

    However, on the active controll of the GND-line: Is the nRF528xx able to sink 5mA via its GPIOs or do I need an external transistor? I have more then enought GPIOs. So I could dedicate one separate GND-supply pin for both sensors. 

    Edit: I already have a Adafruit Feather nRF52840 here for first tests and tried to power the sensors from GPIOs  yesterday evening and it worked fine. So test confirms that its working. I also found the relevant value in the product specification. So 5mA is about one third of the specified max value. I should be fine. No further questions.

    Best Regards, 

    Marco

Related
Terms of service