InsightMike
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 Cashton on 1/10/2024 in #seeking-collabs
High-power Bluetooth Communication
Hi Cashton - sounds like a fun project. Before you get too deep with Bluetooth, I'd start by validating that you can get the range you need. When you describe "high power Bluetooth" - you might be referring to the newer "Coded PHY" protocol for BLE. With great antenna design, this can get you into the 1km ballpark in ideal line-of-sight conditions. But its 2.4GHz, which is particularly poor for moisture. I'd do some snowy field-testing to see if you could get a signal further than you can actually see. Wooded areas and snow covered hills are likely to be problems. If the range turns out to be inadequate, the next technology to look at would be LoRaWAN. It gets you to a lower frequency which does much better in non-line of sight conditions, but much lower data rate, and not as clean of an architecture for your application. Look forward to hearing more about the project!
4 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
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
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