This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Technology design recommendation

I'm designing a  solution based on a series of nodes that senses data and has to send it wirelessly to a hub. Each hub must be able to receive data from about 4 to 8 nodes. The raw data is generated at a rate of about 62000 bits per second by each node. This nodes are supposed to be working with batteries, so power consumption considerations is a must.

I've never develped any wireless device, neither specific comunication protocols, more than simple UART, I2C or SPI comunications,  so I'm pretty newbie about this kind of stufs.

From the things that I've been looking, I was wondering if Bluetooth (or even B Low energy) in a star topology could be a solution, using a pc or a cellphone as hub, but there is a plethora of information on internet and is getting hard to find the ball point.

What could the community suggest me? (including bibliography)

Thanks!

Esteban

  • An important thing i've forgot is the range which is about from 5-6m to 100m.

  • Your throughput is your main limitation. At 62kbps per node X 8 = 496kbps, you're really close to what you can expect to achieve with BLE, but it should be doable with a dedicated BLE Central. The problem with smartphones and PC's is that they use multi-modem radios that have to serve wifi, BT EDR, and BLE at the same time. At 496kbps you're using a lot of radio time, just for BLE, and BLE has the lowest priority of the three protocols, so it will most likely not be able to serve 8 links at 62kbps each. The impact of this problem will also vary from each smartphone model and android version, and the same goes for PC's.

    Your best bet is a dedicated BLE radio, like the nRF52840 as the central device.  

    What is your power budget? 

    Are you able to compress the data on your nodes? 

  • haakonsh: thanks for your reply.

    The application is a lab oriented meassurement system. Each node senses two analog signal (one differential) and reads a n SPI or i2c device (could be any of them).  Eventually, I could use a dedicated ADC via spi/i2c/uart, but if it suits the necessity, I'd go for the ones in the SoC. As it is supposed to be over the members of a person, it shouldn't be heavy in order to enhace conffort. By now, I haven't selected the battery for the nodes. But the central device may be connected to a pc or to the wall, this one doesn't commpromises the power mannagment.

    Do you suggest to use same SoC for the nodes?

    Thanks again!

  • Any 2.4GHz design that is intended for use in close proximity to the human body will require a bit of extra attention with regards to the antenna, but we can help you with HW reviews and antenna tuning.  

    100m line-of-sight might be a bit tricky for a single central due to a lower throughput caused by the lower signal-to-noise ratio at 100m, but you can add another central so each central would only serve 4 links, then you'd have twice the throughput to work with. The only way to know for sure is to test it out in your actual RF environment. 

    Your use-case is at the limit of what you can do with BLE, but I believe it is possible with careful design. BLE devices will use much less energy than BT EDR or wifi, and will, therefore, require a much smaller battery, and therefore, be much smaller and lighter devices overall.

    What are your ADC requirements btw? 

  • Regarding the anthena, at this stage, 100m could be a long term desire, while getting data in a 10mx10m room could satisfy the prototype needs, and a second iteration may evaluate convenience regarding larger range, as you say, testing in the environment. So, do you think that a pcb anthena will work by now?

    My fastest analog signal requires 2kHz sampling, so the 12-bit adc embedded in the nRF52840 or the nRF52832 one will work fine. I see that it has a differential mode, so it will be fine.

    Compression is somthing that I still have it on board, but I've got to perform some test over the signal.

    Thanks!

Related