the data is framed with A, Z and a count. I'm initially just trying to store the data in a small buffer overlapping, but when i run the code im getting some correct values, some really strange ones (i think) the code is simple, and has some errors in overflow i imagine, but i'm just trying to read in the data as a first step!
int index[16];
int i = 0;
void setup(){
Serial1.begin(115200);
Serial.begin(115200);
}
void loop()
{
if(Serial1.available() > 0){
index[i] = Serial1.read();
Serial.println(index[i]);
i++; //Re-write the index with new values each time it reaches 16?
}
}
when i convert the data from binary (when it displays in the terminal program (which works fine)) i get outputs:
A¹ÐÒÀçëïZ
when converted to text string.. couldd the &# and ; be the reason for my strange numbers? and how do i get rid of them
The datasheet says that the device defaults to binary mode, so the accelerometer data you're getting may well be non-obvious ascii characters. Use option 2 to set it to text mode if you want to echo it to the terminal. You should really adddress that buffer overflow you have going on too, before you try to make more progress.
I've set the mode to Binary, and auto run, so it doesn't require an input
and in ASCII the each number is delineated with a TAB, could that be those characters?
if so how do you remove that from the read in?
Also how can i stop the buffer overflow, just increase the 'indices[16]' to 'indicies[500]' as a quick fix?
any help or tutorials you could point me too are much appreciated. I spent a week trying to fiddle with the gps example
code on the main site to suit my needs, but got even worse garbage as i couldn't work out how to parse the code properly..
and in ASCII the each number is delineated with a TAB, could that be those characters?
If, as you said, you set the mode to binary, then no, they can't be. Binary mode does not utilize any delineation (since each data is exactly 2 bytes) You are printing out the binary data, so you are not going to get any useful human readable output. If you want to just output the readings, use ASCII mode. Otherwise you are going to have to handle the conversion to human readable (as well as reading in the data properly).
On a side note, I have to criticize that device for using ASCII delimiters in a binary mode. Poor design choice there. The LSBs of any of those datapoints could easily be 65, making it impossible to know for sure you have a start of frame. It's an unlikely scenario to be sure, but not impossible.
i just read through your blog, and will try a method similar to your gps examples in the morning! (in Australia).
how will i know how many bytes to read in for the data though?
or if i serial1.read() should it just pick it all up and display it?
Because i tried outputting via ASCII but could only find examples where its gps outputs and the code(s) i wrote didn't work so i thought i had to try it in binary/byte format (im a complete beginner to coding until 3 weeks ago unfortunately).
how will i know how many bytes to read in for the data though?
In ASCII mode, you won't know exactly how many bytes you need to read in. Each value can range from 1 to 4 characters. You just need to make sure your buffer is large enough to read in the max string length (ie the possibility of each value being the full 4 characters), and read characters in till you reach your delimiter character (in this case, the letter Z).
So i completely redid my code according too JHaskell's blog's advice.. but im still getting garbage outputs, this time they're all numbers atleast which i guess is good.
my code is:
char buffer[1000]; //initialise buffer 1000 to allow for excess data
int index = 0; //index region for buffer
void setup(){
Serial1.begin(115200);
Serial.begin(115200); //begin serial connections
}
void loop()
{
char startChar = 'A'; //start of data stream
char endChar = 'Z'; //end character of data stream
boolean storeString = false;
while(Serial1.available()>0){
char incomingbyte = Serial1.read();
if(incomingbyte==startChar){
index = 0;
storeString = true;
}
if(storeString){
if(incomingbyte==endChar){
buffer[index] = 0;
storeString = false;
}
else{
buffer[index++] = incomingbyte;
}
}
}
}
would a buffer size of 1000 be to big to store data?
I also think my location of Serial.println() is wrong in the code.. but i tried it in each section and still got bogus results.
I'm using an Arduino Mega, and i just wanted to make sure i could read the data, as previously i had it far to small.. i guess i'll shorten it now though!
I also must've removed my Serial.println() before i posted this code, as it was giving bad values. Any ideas where it SHOULD be placed?
I also changed my storeString variable to Global as suggested by Graynomad.
I'm just a complete beginner with this stuff, i can read in individual accelerometers etc. and gps, using TinyGPS but this ASCII text has me completely confused!
I'm just a complete beginner with this stuff, i can read in individual accelerometers etc. and gps, using TinyGPS but this ASCII text has me completely confused!
A hint, then. The TinyGPS class reads ASCII data from the GPS.
But, what does reading ASCII data have to do with reading binary data (as the topic implies)? Time to back up and explain again to those of us (OK, just me) with short attention spans.
thanks for your reply. i'll have to investigate how the actual TinyGPS library works then.
I'm trying to read in data from an IMU,
it has start character A and end character Z, a count, and each 3 digit number (3 accel, and 3 gyro) separated by a TAB
it can out put in either binary or ASCII mode, originally i was trying to read in binary and convert, but it was explained to me that this is more difficult than just reading the data in as ASCII, so i changed the inertial measurement unit's output from binary to ASCII, and tried to write code to do that.
However I just can't seem to work out what i'm doing wrong, as it seemed right, searching for start and end characters, placing it in a buffer etc.
Thanks for your help. I might have to edit the thread to ASCII not binary.. my mistake!
BTW, I don't think TinyGPS will help you - the output from this device looks to be a custom format, and from what I can see, TinyGPS processes NMEA. I have never used it though, so take that with a grain of salt.
BTW, I don't think TinyGPS will help you - the output from this device looks to be a custom format,
The point of looking at TinyGPS is that it collects ASCII data as it arrives. When the data that has arrived includes an end of packet marker, it then parses the data and resets the buffer to collect more data.
These are all things that OP is trying to learn how to do.
when i open the serial monitor using Serial.println(buffer) (i also tried buffer[index] but i think that's wrong) i get 5 or 6 blank lines,
followed by:
Ar0 í eý è ì ï
In which every value varies apart from the A, the spacing remains the same, i.e. a TAB seems to present between the 4th and 5th character.
What is interesting is the second and third characters after the A are miss reading, as it is the count value in the data. In the print out, the second character moves through the ASCII system, every 10-15 prints, the third one moves through the ASCII system for each number.
So i can guess its reading in the count, but doing so in ASCII, and increasing a number each time or something..
So i'm getting there slowly!
any ideas from here? because its reading in something atleast!
I'm getting a bit lost now, I thought we had established that the data was in binary format.
If that's the case you cannot use print(buffer), you have to scan the array and send each byte with
print(buffer[index],HEX);
OK, now I see this
i changed the inertial measurement unit's output from binary to ASCII,
With the data you are showing I can only assume that it is still not transmitting ASCII, if it was you would see meaningful characters (with the possible exception of the TAB, I don't know what the serial monitor would do with that).
Do the loop to print buffer contents in HEX, that's the only way to see exactly what you are getting.
repeats this pattern a few more times, then gives tonne of zero's, and starts again.. I can see though, that 41 is A, and 5A is Z, with 9 = TAB, i'm just not sure what FFFFFF## means, and how to make it show values nicely in the serial moniter, so i can start parsing the values for use
they do make quite a bit of sense, the ASCII output for the IMU in the serial program looks like this:
A TAB Count TAB accelx TAB accely TAB accelz TAB gyro1 TAB gyro 2 TAB gyro 3 TAB Z. (then start a new packet)
The sensor data goes from 0 to 1023, and the count goes to 32767.
So the output looks very similar, i'm not sure where the rest of the Tab's went, or why i get a sequence of zero's however though.
the buffer is still in char, if i change it to a long, it does output differently but i don't quite understand it, if it should be a long though, i'll have a go at deciphering the HEX format.