InsightMike
DIIDevHeads IoT Integration Server
•Created by wafa_ath on 4/20/2024 in #📡-edge-networking
between mqtt and Coap
MQTT is my vote with the exception of highly constrained devices that would be overwhelmed by the overhead of TCP. MQTT, and potentially SparkplugB are well suited to SCADA type automation.
4 replies
DIIDevHeads IoT Integration Server
•Created by Camila_99$$ on 4/12/2024 in #general-dev-chat
Okk thank you Mike I’m curious, 🧐 have
Each technology has its own "best fit" applications. LoRaWAN is effectively a network so has a number of networking related functions that wouldn't be necessary for point to point communications, which means the receiver is actually a "gateway" so has more hardware and software involved. You can also just use the physical layer, "LoRa" without using the LoRaWAN network stack, but that becomes a more proprietary solution. Bluetooth with the coded PHY feature is likely the easiest integration and lowest hardware costs for your point to point needs. At 2.4GHz, it will be more affected by the trees in your signal path than LoRa will. It should still have enough margin tomeet your range needs - but good to test that in the field first!
1 replies
DIIDevHeads IoT Integration Server
•Created by boualleg sabrina on 4/8/2024 in #📡-edge-networking
RFID
This is a big topic, there are a number of technologies that are evolving to address indoor location/tracking, but they all have their own unique properties. Bluetooth is adding features such as time-of-flight and HADM (now called channel sounding). Those are worth reading up on. Also Ultra Wide Band (UWB) is another technology targeting location/tracking applications. Cost, power, range, accuracy and infrastructure requirements are all factors to consider.
3 replies
DIIDevHeads IoT Integration Server
•Created by Chimmuanya Okere on 2/29/2024 in #📡-edge-networking
LoraWan Network
It takes quite a lot of density to become a problem, but another strategy is to shift to a distributed/edge LNS such that gateways are no longer packet forwarders and the only forward your payloads to the application server (instead of all LW traffic).
4 replies
DIIDevHeads IoT Integration Server
•Created by Camila_99$$ on 2/13/2024 in #📡-edge-networking
Implementing LoRaWAN for long-range communication in a low-power IoT sensor network
Hi Ben - its quite hard to make the LoRaWAN gateway very low power since it's listening for asynch sensor data, and they're most all on linux which is difficult to make work in a very fast "wake" cycle. The sensors themselves are very power efficient.
16 replies
DIIDevHeads IoT Integration Server
•Created by Camila_99$$ on 2/13/2024 in #general-dev-chat
Hiii Mike , yes l’m working on an
That's a great application for LoRaWAN, should have no coverage problems with a single gateway, as long as there aren't severe obstructions. An additional architectural decision to make is whether to host your LoRaWAN Network Server (LNS) on the gateway itself (some gateway mfg's offer this, not all), or remote/cloud. Managing your own LNS (Chirpstack, etc) is more effort than most realize so I'd consider a commercial LNS provider. The other consideration is that you'll have to decode the sensor payload once you receive it at the application level (LW doesn't define a standard sensor payload). Your sensor vendor(s) will be able to provide the info for that.
1 replies
DIIDevHeads IoT Integration Server
•Created by Umesh Lokhande on 2/7/2024 in #general-dev-chat
I would like to monitor the DC Voltage
Hi Umesh, a simple method is just a resistor divider to bring the voltage down to the safe level of your A/D input. For safety, consider following that with an analog optocoupler to provide an isolation barrier between your high voltage and low voltage circuits.
2 replies
DIIDevHeads IoT Integration Server
•Created by Aditya thakekar on 1/17/2024 in #🟩-pcb-and-analog
EMI EMC Testing
For embedded products, its usually the firmware that's the longest development path. Most compliance testing can be done without the production FW. One approach I've used is that once we have the hardware built and BSP FW done, have an seperate developer write the EMC test FW in parallel to the team writing the application FW. For wireless products, or sleepy products, you usually require special EMC FW to excercise the product during testing anyway. This way, EMC testing can be either complete, or at least completely de-risked in parallel to the application FW development process.
13 replies
DIIDevHeads IoT Integration Server
•Created by nour_oud on 12/19/2023 in #devheads-feed
An innovative wireless switch could cut home wiring costs in half.
I'd suggest it's the traditional "make a much better product" then working on the challenges of the ecosystem. In this case, better for who? A harvesting, wireless switch does lower copper and installation cost paid by the building owner, but the building owner is rarely the one to specify electrical components. Architects/designers must be won over to specify them on designs, builders/electricians must be trained and any of their objections must be overcome, regulatory/compliance groups (building inspectors, for example) must be educated on the solution. I'd suggest a standard, driven by an ecosystem of providers, such that there would be seemless interoperability between mfg's, eliminating single-source risks, as well as banding together to promote the solution across the ecosystem (perhaps an extension for Matter?). Interesting challenges!
7 replies
DIIDevHeads IoT Integration Server
•Created by nour_oud on 12/19/2023 in #devheads-feed
An innovative wireless switch could cut home wiring costs in half.
Cool stuff, but difficult to bring to mass market, and compeition ( harvesting wireless light switches) exists. The challenge is that the volume market would be new construction. In most of the US, the copper wire used for lighting (14-2 Romex) is about $0.30 per foot plus the electrician labor to pull the wire. Getting the construction ecosystem to switch to a labor saving method is tough work. But for the DIY retrofit and home automation market its pretty interesting. The challenge of the home automation market has been the very long ROI, which has kept it largely out of maintstream. I'm a big fan of energy harvesting based solutions in general. I've always felt that anything battery powered ultimately has a problem with scale (including a number of industrial wireless products of my own).
7 replies
DIIDevHeads IoT Integration Server
•Created by techielew on 12/8/2023 in #☁-iot-cloud
Need FOTA update help for nRF5340 with Semtech SX1262 LoRa Module
But before you go too deep, consider what the impact on battery life will be if you perform a FUOTA. In some cases, one or two FW updates could consume the battery. The most practical approach, although imperfect, may just be to do a BLE FW update and require local interaction.
4 replies
DIIDevHeads IoT Integration Server
•Created by techielew on 12/8/2023 in #☁-iot-cloud
Need FOTA update help for nRF5340 with Semtech SX1262 LoRa Module
This isn't a mature space. You've probably seen some of the material from TTN on this subject, https://www.thethingsindustries.com/news/introducing-the-firm-update-over-the-air-fuota-feature-for-lorawan-devices-using-the-things-stack/.
4 replies
DIIDevHeads IoT Integration Server
•Created by Saßì on 12/2/2023 in #🪲-firmware-and-baremetal
Microcontroller Selection for My loT edge device
Regarding LoRaWAN - seeing lots of adoption in enterprise environments, commercial space, retail, warehouse. It also shines in outdoor, environmental, ag applications. The ecosystem is strong and growing, a number of good choices for gateway providers, and good architecture flexibility in public/private/local network server choices. The one point I don't like is that LoRaWAN is dependent on LoRa and LoRa (the physical layer) is proprietary to Semtech. So unlike wifi, BT, it's not a licensed technology adopted across many vendors. That said, Semtech did perform well through the supply chain crisis over the last few years and LoRa is clearly a strategic growth segment for them.
11 replies
DIIDevHeads IoT Integration Server
•Created by Saßì on 12/2/2023 in #🪲-firmware-and-baremetal
Microcontroller Selection for My loT edge device
A few tips on the selection process; a) Look at the vendors track record for EOL processes, b) look at parts that are in the "young" end of their lifecycle yet mature enough to have gained popularity, c) look at parts with broad adoption, talk to your disti's to get info on which parts have lots of customer/design wins, d) identify and design in/qualify alternative parts wherever possible on the front end, often simple design tweaks will allow your production pcb to support alternative parts, and where possible, get those alternative parts listed in your compliance reports, e) learn what the suppliers supply chain looks like, are they fabless, are they on "mainstream" fab processes or on legacy (for example, 8" wafers). f) for high risk parts, place long term orders to secure the supply chain (with a trusted disti, this could be a chapter in itself). Finally (actually, firstly), do a bit of risk analysis. How long is the expected lifecycle, what is the engineering cost of redesigns, the compliance cost, revenue risk.
11 replies
DIIDevHeads IoT Integration Server
•Created by Saßì on 12/2/2023 in #🪲-firmware-and-baremetal
Microcontroller Selection for My loT edge device
"cost optimization" is tricky - needs context. Is it "lowest possible COGs" or, "least likely to require redesign NRE due to component EOL" or "most robust supply chain for an X year product life cycle?" Many of us have gone through cycles of COGs/Labor reductions that made our supply chains increasingly fragile - without recognizing that risk until it came back to bite us. In any case, sticking with standards based schemas and protocols will give you a good combination of cost and flexibility. LoRaWAN is certainly a good wireless choice for long range/low power sensor data and gives you an ecosystem of suppliers to work with.
11 replies