So, I have worked on large systems in the past, like an iso stack session layer, and something like that is too big for what I need, but I do have some understanding of the big picture. What I have now is a serial point to point communications link, where some component is dropping data (often).
So I am going to have to write my own, reliable delivery system using it for transport. Can someone point me in the directions for basic algorithms, or even give a clue as to what they are called? I tried a Google, but end up with post graduate theories on genetic algorithms and such. I need the basics. e.g. 10-20 lines of pure C.
XMODEM. It's old, it's bad, but it is widely supported both in hardware and in software, with libraries available for literally every language and market niche.
HDLC - High-Level Data Link Control. It's the protocol which has fathered lots of reliable protocols over the last 3 decades, including the TCP/IP. You can't use it directly, but it is a template how to develop your own protocol. Basic premise is:
every data byte (or packet) is numbered
both sides of communication maintain locally two numbers: last received and last sent
every packet contains the copy of two number
every successful transmission is confirmed by sending back an empty (or not) packet with the updated numbers
if transmission is not confirmed within some timeout, send again.
For special handling (synchronization) add flags to the packet (often only one bit is sufficient, to tell that the packet is special and use). And do not forget the CRC.
Neither of the protocols has any kind of session support. But you can introduce one by simply adding another layer - a simple state machine and a timer:
session starts with a special packet
there should be at least one (potentially empty) packet within specified timeout
if this side hasn't sent a packet within the timeout/2, send an empty packet
if there was no packet seen from the other side of communication within the timeout, the session has been termianted
one can use another special packet for graceful session termination
That is as simple as session control can get.
There are (IMO) two aspects to this question.
Firstly, if data is being dropped then I'd look at resolving the hardware issues first, as otherwise you'll have GIGO
As for the comms protocols, your post suggests a fairly trivial system? Are you wanting to validate data (parity, sumcheck?) or are you trying to include error correction?
If validation is all that is required, I've got reliable systems running using RS232 and CRC8 sumchecks - in which case this StackOverflow page probably helps
If some components are droping data in a serial point to point link, there must exist some bugs in your code.
Firstly, you should comfirm that there is no problem in the physical layer's communication
Secondly, you need some konwledge about data communication theroy such like ARQ(automatic request retransmission)
Further thoughts, after considering your response to the first two answers... this does indicate hardware problems, and no amount of clever code is going to fix that.
I suggest you get an oscilloscope onto the link, which should help to determine where the fault lies. In particular look at the baud rate of the two sides (Tx, Rx) to ensure that they are within spec... auto-baud is often a problem?!
But look to see if drop out is regular, or can be sync-ed with any other activity.
on the sending side;
///////////////////////////////////////// XBee logging
void dataLog(int idx, int t, float f)
{
ubyte stx[2] = { 0x10, 0x02 };
ubyte etx[2] = { 0x10, 0x03 };
nxtWriteRawHS(stx, 2, 1);
wait1Msec(1);
nxtWriteRawHS(idx, 2, 1);
wait1Msec(1);
nxtWriteRawHS(t, 2, 1);
wait1Msec(1);
nxtWriteRawHS(f, 4, 1);
wait1Msec(1);
nxtWriteRawHS(etx, 2, 1);
wait1Msec(1);
}
on the receiving side
void XBeeMonitorTask()
{
int[] lastTick = Enumerable.Repeat<int>(int.MaxValue, 10).ToArray();
int[] wrapCounter = new int[10];
while (!XBeeMonitorEnd)
{
if (XBee != null && XBee.BytesToRead >= expectedMessageSize)
{
// read a data element, parse, add it to collection, see above for message format
if (XBee.BaseStream.Read(XBeeIncoming, 0, expectedMessageSize) != expectedMessageSize)
throw new InvalidProgramException();
//System.Diagnostics.Trace.WriteLine(BitConverter.ToString(XBeeIncoming, 0, expectedMessageSize));
if ((XBeeIncoming[0] != 0x10 && XBeeIncoming[1] != 0x02) || // dle stx
(XBeeIncoming[10] != 0x10 && XBeeIncoming[11] != 0x03)) // dle etx
{
System.Diagnostics.Trace.WriteLine("recover sync");
while (true)
{
int b = XBee.BaseStream.ReadByte();
if (b == 0x10)
{
int c = XBee.BaseStream.ReadByte();
if (c == 0x03)
break; // realigned (maybe)
}
}
continue; // resume at loop start
}
UInt16 idx = BitConverter.ToUInt16(XBeeIncoming, 2);
UInt16 tick = BitConverter.ToUInt16(XBeeIncoming, 4);
Single val = BitConverter.ToSingle(XBeeIncoming, 6);
if (tick < lastTick[idx])
wrapCounter[idx]++;
lastTick[idx] = tick;
Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => DataAdd(idx, tick * wrapCounter[idx], val)));
}
Thread.Sleep(2); // surely we can up with the NXT
}
}
Related
I use SIM800L GSM module to detect incoming calls and generally it works fine. The only problem is that sometimes it takes up to 8 RINGS before the GSM module tells arduino that someone is calling (before RING appears on the serial connection). It looks like a GSM Network congestion but I do not have such issues with normal calls (I mean calls between people). It happens to often - so it cannot be network/Provider overload. Does anybody else had such a problem?
ISP/Provider: Plus GSM in Poland
I don't put any code, because the problem is in different layer I think
sorry that I didn't answer earlier. I've tested it and it turned out that in bare minimum code it worked OK! I mean, I can see 'RING' on the serial monitor immediately after dialing the number. So it's not a hardware issue!
//bare minimum code:
void loop() {
if(serialSIM800.available()){
Serial.write(serialSIM800.read());
}
if(Serial.available()){
serialSIM800.write(Serial.read());
}
}
In my real code I need to compare calling number with the trusted list. To do that I saved all trusted numbers in the contact list on the sim card (with the common prefix name 'mytrusted'). So, in the main loop there's if statement:
while(mySerial.available()){
incomingByte = mySerial.read();
inputString += incomingByte;
}
if (inputString.indexOf("mytrusted") > 0){
isTrusted = 1;
Serial.println("A TRUSTED NUMBER IS CALLING");
}
After adding this "if condition" Arduino sometimes recognize trusted number after 1'st call, and sometimes after 4'th or 5'th. I'm not suspecting the if statement itself , but the preceding while loop, where incoming bytes are combined into one string.
Any ideas, what can be improved in this simply code?
It seems, I found workaround for my problem. I just send a simple 'AT' command every 20 seconds to SIM800L (it replies with 'OK' ). I use timer to count this 20 seconds interval (instead of simply delay function)
TimerObject *timer2 = new TimerObject(20000); //AT command interval
....
timer2->setOnTimer(&SendATCMD);
....
void SendATCMD () {
mySerial.println("AT");
timer2->Stop();
timer2->Start();
}
With this simple modification Arduino always sees incoming call immediately (after 1 ring)
I am creating a game using the Mifare tags embedded in 8 different playing pieces. I will be using an Arduino NANO with the MFRC522 (library https://github.com/miguelbalboa/rfid) to do the actual reading of the tags, and am using an ER301 reader/writer (with eReader software) to assign playing piece numbers to them. I will be creating multiples of each piece to head off any issues I would have with loss due to breakage or theft (due to these being rather unique playing pieces). Since there will be 8 different pieces, and 4 copies of each piece, that would be 32 UIDs to keep up with. I would rather assign a different number to each of pieces, and the same number of each piece to its duplicates - so only 8 numbers to keep up with.
My question is - how do I read a certain block and sector with the MFRC522?
Specifically, sector 2, block 8 - because this is where the Hex equivalent of the playing piece number shows up (when it is assigned as a Product Name with the eReader software and the ER301 writer). I understand using the library for the MFRC522 to read the UID, but this is a bit more in-depth than my understanding.
I have written several Sketches for the Arduino, but this is my foray into the world of RFID, and is quite a bit more extensive than my previous Arduino projects. Once I can read the specific sector & block, the Arduino NANO will output a binary representation (on 4 of the digital I/Os) of which playing piece was placed.
The library you are using provides dedicated methods to perform read and write operations on MIFARE tags:
StatusCode MIFARE_Read(byte blockAddr, byte *buffer, byte *bufferSize);
StatusCode MIFARE_Write(byte blockAddr, byte *buffer, byte bufferSize);
Since your description (sector 2, block 8) suggests that you are using MIFARE Classic tags, you would also need to authenticate to the tag in order to perform read/write operations. Thus, you would also need the authentication method:
StatusCode PCD_Authenticate(byte command, byte blockAddr, MIFARE_Key *key, Uid *uid);
Just as you would use the library to read the UID
if (mfrc522.PICC_ReadCardSerial()) {
Serial.print(F("Card UID:"));
dump_bytes(mfrc522.uid.uidByte, mfrc522.uid.size);
}
you could also access these read/write methods:
MFRC522::StatusCode status;
MFRC522::MIFARE_Key key;
byte buffer[18];
byte size = sizeof(buffer);
for (byte i = 0; i < MFRC522::MF_KEY_SIZE; ++i) {
key.keyByte[i] = 0xFF;
}
if (mfrc522.PICC_ReadCardSerial()) {
status = mfrc522.PCD_Authenticate(MFRC522::PICC_CMD_MF_AUTH_KEY_A, 8, &key, &(mfrc522.uid));
if (status == MFRC522::STATUS_OK) {
status = mfrc522.MIFARE_Read(8, buffer, &size);
if (status == MFRC522::STATUS_OK) {
Serial.print(F("Data (block = 8): "));
dump_bytes(buffer, 16);
}
}
}
Note that I assume block 8 (= sector 2, block 0) to be readbale using key A and that key A is set to the default transport key FF FF FF FF FF FF. If your other reader changed those values, you need to adapt the code accordingly. Moreover I used the pseudo-method dump_bytes(array, length) to indicate that the interesting value is the first length bytes of array. An implementation that actually prints those values is up to you.
Btw. a full example on how to use the library for read/write operations actually ships together with the library!. So you could just take a look at ReadAndWrite.ino on how to use that library.
I am currently working on a simple serial interface on a UNIX based device and cant find a definitive answer to the following:
I am currently trying to determine if a 'pure time read' (VMIN = 0, VTIME >0) will return half way through reading to n_bytes, as the timer is started when read is called, not when the first character is received.
For example, if I send a message to the device on the other end of the serial interface and I want a response I'd attempt the following (pseudo code):
m_tty.c_cc[VMIN] = 0;
m_tty.c_cc[VTIME] = 5; //i.e. > 0
write(myFileHandle, myData, sizeof(myData));
usleep(sizeof(myData) * 100); //assuming 100 us per char to Tx.
read(myFileHandle, myRxData, expectedMinNumBytes);
I am unclear as to whether read() would return if the first byte arrived just as the timer was about to expire, or if it would continue until 'expectedMinNumBytes' once the first is received?
Thanks for the help in advance!
This is a pure timed read. If there is available data, the read is immediately satisfied. If there is no data, the timer is started at the time read is called, and the read returns: either because the timer expires (returns 0) or a single byte is available.
I'm having a bit of a problem with the communication to an accelerometer sensor. The sensor puts out about 8000 readings/second continuously. The sensor is plugged in to a usb port with an adaper and shows up as com4. My problem is that I can't seem to pick out the sensor reading packets from the byte stream. The packets have the size of five bytes and have the following format:
High nibble Low nibble
Byte 1 checksum, id for packet start X high
Byte 2 X mid X low
Byte 3 Y high Y mid
Byte 4 Y low Z high
Byte 5 Y mid Y low
X, y, z is the acceleration.
In the documentation for the sensor it states that the high nibble in the first byte is the checksum (calculated Xhigh+Xlow+Yhigh+Ylow+Zhigh+Zlow) but also the identification of the packet start. I'm pretty new to programming against external devices and can't really grasp how the checksum can be used as an identifier for the start of the package (wouldn't the checksum change all the time?). Is this a common way for identifying the start of a packet? Does anyone have any idea how to solve this problem?
Any help would be greatly appreciated.
... can't really grasp how the checksum can be used as an identifier for the start of the package (wouldn't the checksum change all the time?).
Yes, the checksum would change since it is derived from the data.
But even a fixed-value start-of-packet nibble would (by itself) not be sufficient to (initially) identify (or verify) data packets. Since this is binary data (rather than text), the data can take on the same value as any fixed-value start-of-packet. If you had a trivial scan for this start-nibble, that algorithm could easily misidentify a data nibble as the start-nibble.
Is this a common way for identifying the start of a packet?
No, but given the high data rate, it seems to be a scheme to minimize the packet size.
Does anyone have any idea how to solve this problem?
You probably have to initially scan every sequence of bytes five at a time (i.e. the length of a packet).
Calculate the checksum of this "packet", and compare it to the first nibble.
A match indicates that you (may) have packet alignment.
A mismatch means that you should toss the first byte, and test the next possible packet that would start with what was the second byte (i.e. shift the 4 remaining bytes and append a new 5th byte).
Once packet alignment has been achieved (or assumed), you need to continually verify the checksum of every packet in order to confirm data integrity and ensure packet data alignment. Any checksum error should force another hunt for correct packet data alignment (starting at the 2nd byte of the current "packet").
What you need to do is get some free SerialPortTerminal in c# import in your project and first check all the data and packets you are getting, unless you have already done that. Than just to read you will need to do something like...
using System;
using System.IO.Ports;
using System.Windows.Forms;
namespace SPE
{
class SerialPortProgram
{
// Create the serial port with basic settings
private SerialPort port = new SerialPort("COM4", 9600, Parity.None, 8, StopBits.One);
[STAThread]
static void Main(string[] args)
{
// Instatiate this class
new SerialPortProgram();
}
private SerialPortProgram()
{
Console.WriteLine("Incoming Data:");
// Attach a method to be called when there // is data waiting in the port's buffer
port.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived);
// Begin communications
port.Open();
// Enter an application loop to keep this thread alive
Application.Run();
}
private void port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
// Show all the incoming data in the port's buffer
Console.WriteLine(port.ReadExisting());
}
}
}
I have a problem with the Arduino communication. It's quite hard to describe so I cant fit it in the title. Anyway here are the following:
So I have this code for my receiving end:
if(Serial1.available())
{
while(Serial1.available())
{
uint8_t inByte = Serial1.read();
inByte = inByte ^ k;
Serial.write(inByte);
}
Serial.println(" done");
}
It's supposed to print in one line and print done when it's done. The Serial1.available() seems to skip the next Serial1.available(), I don't know what's going on. Anyway here's my current, bad, output:
h done
e done
l done
l done
o done
done
when it should be:
hello done
I'm sorry if this could've been phrased better but that's all I can type now, my brain is kinda in pain. I've never experienced this behavior in a Windows c++ console application.
If you are calling that routine in loop() then yes, it will read from the serial buffer and immediately return since you are probably not sending the data fast enough.
A better way to handle this sort of thing is to use a control char which indicates the end of a message OR if you have a specific data format you expect to receive, then keep a count of the chars which have come in until the data format limit is reached.
There is discussion here which you may find useful: Serial Duplex using Arduino Also there are example sketches that ship with the Arduino IDE: Menu: Examples: Communication:
Also, read all the entries under the Serial listing for Arduino. Good stuff there.
So the routine you develop for working with Serial input really depends on your project and the kind of data you are receiving. In your example above, if you were to use a control char, it might look like this:
while(Serial1.available()){
char c = Serial1.read();
if (c == '*'){
Serial.println(" done");
} else {
Serial.write(c);
}
}