I am using a MMA7361 accelerometer from sparkfun that is connected to my arduino uno and it is in turn connected to my pc.
I am simply reading the values from each axis(x,y,z) and sending them straight through the serial port to my pc with a series of Serial.print and Serial.write. From there I have set up a program to read and display the info with myPort.readString();
Now it works fine 80% of the time and it gives the right results and all, but sometimes I get some random value sent through the serial port and it messes up the receiving program making me unable to use the signal properly.
I am pretty sure its not the sensor itself sending the disturbing signal because I have tried to save 10 different readings and then sending an average to minimize the effect with no luck. The receiving pc still got the weird value spikes around 0-200 (from what I saw as output).
I tried with pulling out the cable that connects from the sensor to the analog in port and weirdly it gave out some random value instead of the expected 0, I'm not sure but for me it seems like that has something to do about my problem.
I have read about some kind of pull down resistor but that only works for buttons, right?
I just got my arduino and I'm trying to learn how to use sensors and what you can do with them and what can go wrong so I'd appreciate if someone could help me with this :)
Heres an example of the random value messing up the output:
252:236:218
251:202:215
2 <-- this is where it begins
59:231:245
28
4:144:142 <-- messing up the order of the values
251:19
2:187
246:235
:244
240:190:
238
250:202:2
32
248:243:224
245:227:240
251:228:244
253:223:241
If you want I got the code for sending and recieving too:
Serial.print(analogRead(xpin));
Serial.write(":");
Serial.print(analogRead(ypin));
Serial.write(":");
Serial.println(analogRead(zpin));
I'd really like the sending to be just one line of code but I haven't been able to join all numbers and strings to a one line string on the arduino.
Recieving:
if ( myPort.available() > 0) {
result = myPort.readString();
println(result);
}
Looking at your output, it seems that the values are all received, but somehow a CR and/or LF character is added to the output. And that comes from the println statement:
if ( myPort.available() > 0) {
result = myPort.readString();
println(result);
}
What happens is that the receiving end gets some characters (not necessarily all), it prints them, adding a linefeed character then exits the function.
Then it enters the if statement again and prints the available characters in the buffer. And so it goes.
If you wish to ensure a consistent output you have to either
1. build a packet of the data or
2. Count the received bytes and print them when all are received.
As to 1. it would be my preferred method, add a start- and end-character to the data. The receiving end will then know that all data between the start- and end-character is the data to be printed.
I seem to have fixed this by using readChar and checking if the current character inputted is the delimiter. It is a bit slower but it works.
Related
I am building a SD card/SCSI adapter using NCR 53CF94 IC and STM32.
All goes pretty well, even manged to make my device work to some degree, i.e. accepting all basic commands and even booting from it to DOS. BUT i have a problem, when asking initiator (PC) to write something to my device , all goes well i get the block address and the data. Then i write the data to SD card and finally responding with status=0 and message=0 to complete the write command, but the initiaor never increasing the secoor number to continue to write proccess and always tries to write the first one, then after few attempts it gives error on the PC (Error writing to drive...). I can't figure it out why the initiaor is not satisfied with the GOOD status and message. Do i need to send some specific data back to the initiator ? Linke CRC ? Or there is some specific command i need to issue for 53C94 ?
Banging my head for few days now.
Need your assistance please.
Thanks !
Artiom.
I figured it out. I was writing 512 byte blocks to a 256 byte array. I'm not sure how this is related to the issue, but after fixing the size everything started to work.
Anyone here using MikroC to implement UART?
I'm trying to connect a PIC18F4550 and SIM900. I want to use UART1_Read_Text(variable, delimiter, attempts). But since there is no specific length of the text that will be received, I'm trying to use NULL as the delimiter but none seems to work. I tried putting "\0", "0"," enter code here" but the microcontroller is stuck in that line of code. Here is the sample code i tried.
UART1_Read_Text(variable,"\0",255) //255 means the PIC will continuously find the NULL
Just so you know, I'm expecting to receive either "OK" or "ERROR". The PIC will then repeat a certain line of code if it receives "ERROR".
I am using the internal oscillator (FOSC = 7.37 Mhz) of the dsPIC33EV256GM102. I have a 1602 LCD connected to the PIC via 4 data, and enable, RW, and RS control lines.
I write initialization commands to the LCD and then two lines of text. That works fine.
After 2 minutes and 10 seconds the enable line quickly pulses high-low causing something to be written to the LCD. It happens again in another 2:10 and then again, repeatably.
All my program does right now is initialize the LCD, write two lines of text and go directly into a while(1).
I have tried setting the LCD enable low on every iteration of the While. I have tried latching the enable low before going into the While. I have moved the enable to another pin but the pulse still occurs on that pin. If I remove the enable line after writing the data, the problem goes away.
Any thoughts what might cause this kind of behavior or what additional troubleshooting steps I might take?
I am using pin 24 labeled RPI45/PWM1L2/CTPLS/RB13 for the enable but I have also tried pin 23 labeled RPI44/PWM1H2/RB12. I am not executing any code related to peripheral pin select yet.
When I download the program via the Pickit3, for the first POR while the Pickit3 is still in the circuit, there is some spurious text written to the LCD. So I have to disconnect the Pickkit3 and do another POR before the two line of text are written correctly without any unwanted additional data writes.
In conclusion there are two issues really or perhaps they are related?
I would like to do 2 things.
Recognize when someone is calling - In terminal will appear RING and to answer I have to send command ATA. But How can I recognize it when I am doing something else. Should I use new thread and read port until send RING? Is there any beter solution?
What is a symbol of end of response? I'm reading char using for(), but I do not know number of signs. Example below doesn't work properly
while(readCharUART()!=10) {};
while(readCharUART()!=13)
{
getchar() = ..
}
You are on the right track.
For RING then yes, the correct way to do it is to have one thread just read modem responses until you get the Unsolicited result code RING. If you from time to time want to run AT commands (say ATA), then you should let this thread do that as well, e.g. you have one thread that takes care of both issuing AT commands and monitor for UR codes.
Regarding formatting of responses from the modem, this is well described in chapter 5.7.1 Responses in the ITU V.250 standard. Short summary (reading the spec is highly recommended!):
<header>RING<trailer>
where header and trailer is both "\r\n" (unless the modem is configured strangely).
I'm processing Midi on the iPad and everything is working fine and I can log everything that comes in and all works as expected. However, in trying to recieve long messages (ie Sysex), I can only get one packet with a maximum of 256 bytes and nothing afterwards.
Using the code provided by Apple:
MIDIPacket *packet = &packetList->packet[0];
for (int i = 0; i > packetList->numPackets; ++i) {
// ...
packet = MIDIPacketNext (packet);
}
packetList->numPackets is always 1. After I get that first message, no other callback methods are called until a 'new' sysex message is sent. I don't think that my MIDI processing method would be called with the full packetList (which could potentially be any size). I would have thought I would recieve the data as a stream. Is this correct?
After digging around the only thing I could find was this: http://lists.apple.com/archives/coreaudio-api/2010/May/msg00189.html, which mentions the exact same thing but was not much help. I understand I probably need to implement buffering, but I can't even see anything past the first 256 bytes so I'm not sure where to even start with it.
My gut feeling here is that the system is either cramming the entire sysex message into one packet, or breaking it up into multiple packets. According to the CoreMidi documentation, the data field of the MIDIPacket structure has some interesting properties:
A variable-length stream of MIDI messages. Running status is not allowed. In the case of system-exclusive messages, a packet may only contain a single message, or portion of one, with no other MIDI events.
The MIDI messages in the packet must always be complete, except for system-exclusive.
(This is declared to be 256 bytes in length so clients don't have to create custom data structures in simple situations.)
So basically, you should look at the declared length field of the MIDIPacket and see if it is larger than 256. According to the spec, 256 bytes is just the standard allocation, but that array can hold more if necessary. You might find that the entire message has been crammed into that array.
Otherwise, it seems that the system is breaking the sysex messages up into multiple packets. Since the spec says that running status is not allowed, then it would have to send multiple packets, each with a leading 0xF0 byte. You would then need to create your own internal buffer to store the contents of these messages, stripping away the status bytes or header as necessary, and appending the data to your buffer until you read a 0xF7 byte which denotes the end of the sequence.
I had a similar issue on iOS. You are right MIDI packets number is always 1.
In my case, when receiving multiple MIDI events with the same timestamp (MIDI events received at the same time), iOS does not split those multiple MIDI events in multiple packets, as expected.
But, fortunately nothing is lost ! Indeed instead of receiving multiple packets with their correct number of bytes, you will receive a single packet with multiple events in it and the number of bytes will be increased accordingly.
So here what you have to do is:
In your MIDI IN callback, parse all packets received (always 1 for iOS), then for each packet received you must check the length of the packet as well as the MIDI status, then loop into that packet to retrieve all MIDI events in the current packet.
For instance, if the packet contains 9 bytes, and the MIDI status is a note ON (3 bytes message), that means your current packet contains more than a single note ON, you must then parse the first Note ON (bytes 0 to 2) then check the following MIDI status from byte 3 and so on ..
Hope this helps ...
Jerome
There is a good reference of how to walk through a MIDI packet in this file of a GitHub project : https://github.com/krevis/MIDIApps/blob/master/Frameworks/SnoizeMIDI/SMMessageParser.m
(Not mine, but it helped me solve the problems that got me to this thread)