I'm implementing a Lora network, with two SX1278 modules and Arduino Uno. Lora is based on three classes. A , B and C, The question is : for change For example A to B, what should exactly change in communication?
and How does it change the beacon?. I clearly mean, Does it need to send a particular and standard message to the receiver ? Or Will just communicating in scheduled time change the class or changing some control bits is needed?
about your question
Lora-wan(communication protocol and network architecture that sits on top of the Lora physical layer) is based on the classes not Lora.
the different between them is:
Lora : is a wireless modulation technique derived from Chirp Spread Spectrum (CSS) technology.
Lora-wan : is a Media Access Control (MAC) layer protocol built on top of Lora modulation(((((((((Software Layer))))))).
so what the programmer should know from that?
when you buy any Lora module you should read about the device details if it support the Lora-wan or not?
if your devices support Lora-wan then you can implement the three classes you mention (A,B,C) and those classes created to reduce the power consumption and communication technique ( how is that??) let's see these three type and what can do for us:-
1- class A : simply when you build network contain many nodes and gateway the nodes will send to the gateway and after send will change from send(mode) to receive(listing)mode for responding from the gateway and as you can see the listing in two different time but if node receive from first time it will cancel the second time.((class B and C should support Class A))
2- class B(beacon) : it's addition of class A but take more receive mode at scheduled times
3- class C(ontinuous) : addition to Class A the node after send it will listing the whole time for responding class C take more power due to the continuous listing.
as you can see both class B,C need to support class A.
for more info see:
https://lora.readthedocs.io/en/latest/
Related
I have an Analog Four MK1 connected directly to the computer and to the speakers and used as an Audio Interface in Ableton.
I will get now an Elektron Analog Rytm MKII. and I wonder if I can play both or I should add an Audio Interface like Focusrite Scarlett 2i2 (2nd Gen)
When you route the audio already through the computer this should be easy with OB2.
Or when you don’t want to use OB2 yet, you can also connect the main outs of AR to the inputs of the A4 so you can mix it in.
You can route the rytm through the analog four inputs and do it that way. just turn on the volume (FX track + OSC1 /Ext In).
I have a board with presumably an STM32 mcu. I want to make custom firmware for that board as the stock one is very buggy. Unfortunately the board manufacturers were kind enough to grind off all the markings. Is there any way to get the device/family id via jtag and cross reference it to a model number? Everything I could find was about getting the unique id of the chip, which is NOT what I need.
In pystlink (SWD programmer) is implementation, which almost successfully identify any STM32 MCU.
The principle is:
read PART_NO from register CPUID at address 0xe000ed00 and with this is possible to identify if MCU is CortexM0, M3, M4, .. in this file stm32devices.py
read IDCODE_REG (M0 and M0+ has this register on different address than M3, M4 and M7) first 12bits is DEV_ID, which identify family and again look into stm32devices.py file
read flash size from register FLASH_SIZE_REG (each family has this register on different address) and identify concrete device again by stm32devices.py file
Or simply connect SWD and keep pystlink to detect right MCU.
You can get down to a family of STM32 through the JTAG IDCODE of the device, but getting to the exact part number will require more guessing, like actual flash and ram size, or optional features.
I would do the following:
get IDCODE from boundary scan JTAG TAP, confirm it is ST and STM;
look for it in manuals from ST, get to the family;
see whether the family implements the flash identification feature (some families expose flash size and page size at fixed offsets in memory space);
if not, probe for actual flash size through memory accesses (dichotomy in plausible address space will give good results);
do the same for ram.
At last, you know for sure the package you have on the board. With this, you should be able to narrow down to the matching part number.
If you have access to a boot loader UART you can use stm32flash to identify and program the device, unless it is locked down.
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
I have this GSM embedded device under linux, where depending on external factors I might chose to put a different sim card into. But in the configuration for the PPP, I have to give an APN, which changes depending on the network du jour. How can I automatize that?
It just downed on me that smartphones don't need explicit APN entry to work when changing the sim card (also, the APN is sometimes different in M2M and actual cell phone, not sure I can use the same trick).
(I know you are curious: it's deployed in the middle of nowhere, and we chose the least worst network at the last minute on the installation site)
You can detect the network operator from the IMSI of the SIM, and have in your device a table mapping operators to APNs.
There are several sites that will provide you an IMSI to operator listing or MCC and MNC to operator listing. The MCC (Mobile Country One) is the first three digits of the IMIS and the MNC (Mobile Network code) the next 2 or 3 digits. Some example links:
https://www.imei.info/carriers/
https://www.mcc-mnc.com
As an aside, if you want to be able to change to adapt to the best available network coverage over time, the way many M2M applications achieve this is to use a 'forgein' SIM which can then roam to the best available signal at a given time. If your data usage requirements are low this can be a good way to avoid being dependent on one operator in an area with poor coverage. There are quite a few companies who specialise in these type of M2M sims, depending on your target location.
I'm currently developing a small application for monitoring the power / current our solar collector is generating.
The array is connected to 3 inverters. Every inverter has a RS232 interface, transmitting one Line of information(its current status) every 10 seconds.
Since I want to do the monitoring using a device only having one serial port, I need to come up with a way to be able to read the data from all of the inverters in parallel.
I don't need to send anything to one of the inverters!
Is it possible to just connect 3 RS232 wires in parallel to one serial port? Collisions will be pretty unlikely since every inverter is transmitting only 64Byte / 10seconds ending with a newline, so I could check for variable line lengths to detect collisions.
I'm sort of chuckling at doomsday and wacky answers that so often pop up on stackoverflow...
But anyway, in years gone buy I have used paralleled RS-232 transmit lines using diodes and it can work fine for situations where collisions are unlikely. In one particular application I used this technique there were two input terminals where a user could key in simple commands to control the system (a specialized security system) and it was very unlikely that two people would be trying to control it at the same time from the two different terminals. Amazingly enough there are no problems with voltage levels with most RS-232A receivers I tested at the time and they tolerated the signal characteristics (no negative voltage) that result from the simple use of the diodes in series with the TXD signals. However, if I had to do this again I would likely add a simple pull-down resister and capacitor to ground with a diode between RXD and the cap in a sort of charge pump configuration or a pull-down to negative going handshake signal to ensure the "OR'd" input signal goes truly negative since the RS-232 spec defines +3 to -3v as invalid.
In any case, I would recommend not using this technique except in very specific, limited, and non-mission critical cases and would not use it in the case where you have multiple devices sending information at a programmed interval as in the case of the OP or where there is a software handshake.
In can be a simple solution to the problem of not enough serial input ports but only in a very limited set of environments.
No, you should NOT connect 3 serial output port in parallel. If you do that you are probably going to broke the RS232 output circuitry of your inverters.
You have 3 RS232 outputs, so you need 3 RS232 input, then you can manage these 3 input the way you like: maybe you can buffer the data from each input, and reoutput the data on a single RS232 output, to be connected to your monitoring device.... but you should add some code in the data flow to differentiate the data coming from the 3 inverters.
Maybe you can use some kind of IC that do the job for you, I'm not sure, but maybe that some IC that multiplex multiple RS232 input on a single RS232 output already exist.
Try this search: rs232 port input multiplexer on Google
Or, if the monitoring device is a Window computer, you can use 3 serial-to-usb converter: that will create 3 virtual COM port on your computer and you can read data from them with any software.
Update
About the hypothesis of securing the output circuitry using diods to block reentering current, I don't think it's going to work...
Many year have passed by since last time I've used an RS232 link at low level (so maybe I'm wrong) but I think that there is some kind of handshake going on between RS232 input and output port (speed to use, parity, stop bit...).
Each RS232 port have inputs and outputs signal, both for data and for transmission control, so your multiple RS232 outputs does have some input signals, and your single RS232 input does have some outputs.
This mean that your input monitoring RS323 port is going to try to make a handshake with 3 RS323 ports at the same time... and the 3 RS232 ports are probably going to respond at the same time... so I think it's not going to work.
Other than that if you place diodes on your output, you are going to loose 0.7v, I don't remember the tolerance on signal level of RS232, but maybe that 0.7v can be relevant.