I have been looking into LoRaWAN for a low cost waterproof asset tracker I am looking at building.
AFAIK, the primary benefits of LoraWAN over say LTE-M or cellular are: no connectivity costs and potentially lower power consumption.
What I'm wondering is: why can't we use our own cellphones as the "base station" that the IOT device talks with? We can do this with bluetooth and WiFi, why not cell? Is it the LTE protocol that prevents it? Physics? What am I missing?
There's quite a few architectural reasons why Peer-to-Peer LTE isn't feasible, but the largest is probably the fact that in LTE the uplink and downlink use different modulation techniques.
In the downlink (the connection from the Base stations (eNodeBs) to the User Equipment (our mobile phones)) Orthogonal Frequency Division Multiplex (OFDMA) is used, this means the phone listens out onto the RF interface for the OFDMA signal.
This works well, OFDMA is a great way of encoding the data onto the air interface, but it has a very high peak-to-average-power ratio, this means if the UEs used OFDMA in the Uplink (From the UE to the eNodeB) they'd have awful battery life.
Instead in the Uplink LTE uses Single Carrier Frequency Division Multiple Access (SC-FDMA), which is much more power efficient and allows you talk all day, so the eNodeBs listen on their RF interface for the SC-FDMA modulated traffic.
This means our UEs (Mobile phones) use one type of modulation to send and a different modulation scheme to receive, so they can't talk directly to one another as they can't send OFDMA modulated data, only receive & visa-versa.
Some more reading on OFDMA & SC-FDMA.
The LTE relay interface inducted as part of Release 10 allows the deployment of relay nodes (a kind of low cost eNB) that are fixed and that use in-band LTE to extend the coverage of standard eNodeBs by one hop, improve signal quality and to increase the network capacity. Relays can be placed such that it converts the long single hop into two shorter hops.
However the approach of using UE seems have many challenges as it can make UE to get bit loaded with more functional changes across layers(MAC, PHY, RRC, NAS) as it has to take additional functionalities from Relay nodes/eNB as well ranging from lower layer signalling, co-ordination, mobility to forwarding. Also, there might be additional power consumption and change in antenna to support the same which all will add to more cost of UE.
Related
I would like to create a point-to-point connection between a LoRa temperature sensor and a M5 Stack (ESP32) with LoRa module. However, I am a beginner with LoRa, so I have a few questions:
Are all packets send with LoRa (not LoRaWAN) encrypted? Or does it depend on the producer of the LoRa sensor?
Can the content of the packet received by the M5 Stack be viewed? (If I understand correctly, with the LoRaWAN the content can only be viewed after it is on the server).
Can I send measured temperatures from multiple LoRa sensors to one M5 Stack? If yes, how could I distinguish from which sensor the packet has been sent?
Any help would be appreciated!
LoRa means only the RF modulation. All crypto happens in higher layers, i.e. the protocol stack – one possible option for this is LoRaWAN. LoRaWAN uses AES-128 encryption in two layers, Network and Application. You gave no information about the kind of "LoRa temperature sensor" you have, so it is not possible to make a statement about that, other than that it is not LoRaWAN. So this fully depends on the sensor's firmware. There are alternative protocol stacks to LoRaWAN, DASH7 for example. You also might want to have a look at this Stack Overflow article
This too depends on the used protocol stack. With LoRaWAN, you need a gateway to receive the node's LoRa telegrams which are then forwarded to the LoRaWAN cloud (TTN/TTS, for example). Your application can get them from there via Internet. If there's already a TTN gateway in reach, your nodes would automatically use that.
You can actually use the M5 with its WLAN capability to act as a message consumer for multiple nodes by subscribing to the cloud via MQTT, for example – using LoRaWAN. Using LoRa without LoRaWAN, this again depends on the alternative protocol stack you are using here. Of course this requires a working WLAN in reach.
If you are trying to use plain LoRa, which is possible, it is purely your task to implement all the requirements for managing the communication between all involved nodes; it is also your responsibility to ensure that the legal obligations are met.
I would strongly recommend using LoRaWAN and TTN/TTS as it is the de-facto standard for LoRa communications and offers a complete ecosystem that can be used readily without great effort/cost.
Hi I am using STM32F407ZET6 Microcontroller and I want to use multiple streams of DMA1. Is it possible to trigger two different streams of the same DMA for transferring data to two different peripherals simulatenously. (Like in Parallel).
In the advanced AHB bus matrix I observe that for each DMA there are only two lines, one for memory and one for peripheral, which suggest to me that at any time at max two streams can perhaps run in parallel and that also if none of the streams are really doing memory<->peripheral transfer. Is this assumption correct? And, is this also correct that to run two streams in parallel through a single DMA they should not be doing memory<->peripheral transfer? what I mean is that by the look of AHB matrix it felt if only Mem to Mem and Periph to Periph transfers are done then probably two streams can run in parallel, but if any one of them does memory<->peripheral transfer then the use of DMA memory and peripheral interface for a single transfer will probably make that NOT possible. Can you shed some light on this?
I would like to request some guidance on this particular topic as i could not find satisfactory information on it... And if it is dependent on the bus bandwidth to transfer streams in parallel then how the bandwidth is divided among multiple channels for a single bus to perform multiple transfer.... Some If there is any such example, i would be thankful. As a reference I have put the AHB matrix below:
You can only select one channel per stream, but you can enable all 8 streams per DMA peripheral at once if you like, subject to the hardware defect listed in the errata sheet*.
Each of the masters take turns to access the buses. Once a master takes the bus it decides how long to use it for. For the DMA master, this is configured with the MBURST and PBURST bits of the DMA_SxCR register. If you require very low latency in the system and do not want the processor or another master (ethernet etc) to be stalled and have to wait for the DMA to get off the bus then set the burst configuration short (but even the longest burst you can configure will still only be a microsecond or so).
(*) there is a hardware defect in DMA2 which disallows concurrent use of AHB and APB peripherals, see the errata for details.
I'm wondering if I can do something like this:
Do some image processing with opencv on my pc, do some math and send data to RaspberyPi to PID controller and then control servos, in real time.
UART wolud be the best connection?
In principle you can use any means to communicate from the PC to the Raspberry PI that are available (UART, ethernet, etc.).
However, you just have to be careful about any time requirements you have in the system you are controlling and check whether the communication rate is suitable.
For instance, you can use 9600 baud UART to temperature control, as the dynamics of such systems are usually slow. If your servos control an inverted pendulum, then the communication speed might make it impossible to control.
I'm working on an engineering project where I want a go-kart to maintain a direct connection with a base station. The base and go-kart can be separated by about a half mile (with lots of obstacles in between) which is too far for WiFi.
I'm thinking about using 3G/4G to directly connect the two. Does anyone have any resources or ideas that might help?
Or, alternatively, a better way to connect them? I'm just trying to send some sensor data (pretty low bandwidth) in real-time.
The biggest problem you face is radio spectrum that you are allowed to use. All 3G/4G spectrum is licensed to some firm and they get really unhappy (e.g. have you hunted down and fined) when you transmit in their space.
I did find DASH7 which
is an open source wireless sensor networking standard … which operates in the 433 MHz unlicensed ISM band. DASH7 provides multi-year battery life, range of up to 2 km, indoor location with 1 meter accuracy, low latency for connecting with moving things, a very small open source protocol stack …
with a parts cost around US$ 10. This sounds like it satisfies your requirements and keeps the local constabulary from bothering you.
You could maybe use SMS, between a modem on the kart and a mobile phone or modem at the base.
A mobile data connection like a telephone call isn't possible directly between the two; you have to make a data connection from the kart to a server in your operator's core network, identified by the APN. Then you can access IP addresses as for a normal internet connection - so the base computer would have to be a web server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I had an Idea and I was wondering if it was possible. I've googled it and can't seem to find any existing solutions. I was thinking of having a Bluetooth mesh network. The layout I was hoping to achieve is to have one central station (PC with bluetooth dongle) and then a bunch of bluetooth modules (preferably these) that would all form a mesh network with the modules around them. Not all of them would be in range of the "central station" but would need to communicate with it through the other nodes. The bluetooth modules would be hooked up to ATtiny85 chips if it makes any difference. If you have any questions just ask.
Is this possible?
Is it possible with the above bluetooth module?
Would they all have to be set up individually or could there be some sort of neighbor discovery?
Would there be security risks?
What would the limitations on the size of the network be?
Where should I start?
CSR has delivered a BLE mesh network solution
http://www.csr.com/news/pr/2014/csr-mesh
Not sure if you have found a reasonable solution yet, I am new to the BLE and was also thinking along the same lines of having a BLE mesh that can permit transmitting of signal up to a few miles or so. This way, sensors can be placed in remote rural areas and utilizing multiple hops of sensors, the data can be transmitted to the central controlling station. However, as of yet, I haven't seen a dual mode sensor that can assume both roles as needed.
The other approach can be to make use of TCP/IP bridge. This way, the device, which can be an iPhone or Android, listens to the advertised data, creates an IP packet and send it to the remote server. Obviously, for this to work you need to have cellular data network available. But granting ubiquitous data network or Wi-Fi coverage this solution sounds more promising to me.
NOTE: Here http://www.bluetooth.com/Pages/low-energy-tech-info.aspx they talk about star topology though, below is the excerpt:
Topology – Bluetooth low energy technology uses a 32 bit access address on every packet for each slave, allowing billions of devices to be connected. The technology is optimized for one-to-one connections while allowing one-to-many connections using a star topology. With the use of quick connections and disconnections, data can move in a mesh-like topology without the complexities of maintaining a mesh network.
Also have a look at FruityMesh. It is an open source implementation of a mesh network that is based on standard Bluetooth Low Energy 4.1 connections.
They use the Nordic nRF51 chipset in combination with the S130 SoftDevice.
Found on github: https://github.com/mwaylabs/fruitymesh/wiki
So bluetooth - as clearly pointed out in the comments - is not designed for mesh networking. Nor, honestly would you want to. It would be far to expensive both in fincances AND in processing time and battery power to handle such an operation.
Instead, why not use XBee? https://www.sparkfun.com/search/results?term=xbee&what=products
These XBee modules are not only designed to do EXACTLY what you want, but they are low cost and HEAVILY documented.
A much better choice for your wifi mesh.
well, theoretically it should possible to build a mesh networking behavior with BLE devices, though it has not been designed that way.
The idea would be to use the fact that BLE has been designed so it can work over disconnections.
So you could handle two connections with your device: one as a bluetooth master and the other as a bluetooth slave. Then you could run once as a slave and listen to the next device's services see if there is any event, and if there is, become a master and broadcast the event to the previous device until the event reaches the host. The tricky part would be to tweak the timings so it works fastly and smoothly.
Another way that should be less a hack would be to build an ANT network for the mesh topology, while having BLE to be able to connect each node to Bluetooth enabled devices. You could use something like the nRF51422 to do such thing.
HTH
As I undertand, Bluetooth is something designed to do data transmission with a low power consumption. So compared to 802.15.4, Bluetooth shows a much shorter communication range which means more device maybe used to build a network. And I think BLE is just a name, just some code pre-programmed into chip ROM. Anyone can modify the BLE protocol, if he gets enough coding experience.