how do I query the camera to see if its powered on properly and working?
If you are talking about those linksprite cameras then I suggest you read the manual. For example the one linked to in the product page here at Sparkfun. It explains which bytes must be sent as command (though not in as clear English as hoped for) and it shows what it would reply. If you don’t get that, then either the communication is not working or the device itself is simply not working. Which could be because it isn’t properly powered, or potentially defective. Wiith the proper serial terminal program able to send specific byte number sequences (shown in hexadecimal format for example) you should be able to do this manually without needing any programming.
I have already interfaced with it. I’ve posted here:
http://forum.linksprite.com/index.php?/ … entry11242
I see lots of people posting about this issue. It seems very common but I haven’t seen a clear cut answer.
As you can see I was trying to write to a microsd card. I moved on to just interfacing directly with the camera and the Uno via a mac app called Serial Tools.
I posted here as well:
That code is not really interfacing with the camera if you ask me. It sends a command to it, but ignores the acknowledge response it gets. And doesn’t care if none is sent. Only the image data that is sent is processed. That is to say, it assumes it is image data! But there are no checks if the camera gives the proper response to the given command. So there is no way to be sure the camera is working in that code. Proper interfacing with a device is issuing a command and listening for a response, and interpret it’s meaning. That code may be posted as an example by linksprite, but I wouldn’t put too much value in it. It may work for some, but your mileage obviously varied. It cuts alot of corners compared to what the manual states should happen. The guys in the arduino forum seem to think likewise of it.
You wrote in the first linked thread:
The sketch doesn’t write the file anywhere but it does spit out the data to the serial monitor. Unfortunately Im getting 00 bytes.
I added this line: Serial.print(incomingbyte); but there is already one that prints out the array contents here: Serial.print(a[j],HEX);
It does send the contents of a buffer out to the computer/mac. But this is not the raw data. I would like to see the raw data from the camera to be sure it is responding to the issued commands correctly.
Before that for-loop with the Serial.print(a[j],HEX) statement the incoming data is placed into a byte buffer (in the while loop), but only if certain counter values are in the right range. So that means not all the bytes sent from camera are put into the byte buffer. It is cherry-picking the bytes out of the stream on the assumption that the data is in the correct format. And thus garbage can come out if garbage came in for whatever reason.
Even before that (between calling SendTakePhotoCmd() and declaration of the byte-buffer “a”) you have the while loop putting the myserial data in incomingbyte. This effectively clears the myserial input-buffer. But at least also prints it out to the serial port to the computer so you can see it with a serial monitor. That is to say, IF the camera has had enough time to formulate a response after calling SendTakePhotoCmd. Taking the photo might take a bit of time and causing the while loop to skip if no bytes are in the myserial-buffer yet. And if there are, the difference in baudrates of myserial and the hardware serialport might lead to loosing bytes comming in on myserial while the previous one is sent on the hardware serial port. So what was in your serial monitor up this point?
PS: In the code is a 32 byte array called “a”, but also a long integer index variable named “a” used to point to a place in the image data (in the function SendReadDataCmd ). Now, that may compile correctly since they are different data types and don’t use the same kind of operators. (I think, but it’s late and I’m tired) But I definitely would not name the byte-array that way to avoid mistakes. Actually, both names are not descriptive enough of their meaning. Better to change both.
OK so you’re saying I should do 2 things:
-
Get the response to each command from the camera.
-
Rename the array to something more descriptive.
Of which the second is more cosmetic but good coding practice. I agree, I guess I assumed if the manufacturer posted it, it should be good.
I’d like help on reading the response. I know that if I send:
Send:56 00 26 00
I should get:
Return:76 00 26 00
And if I send:
Send:56 00 36 01 00
I should get:
Return:76 00 36 00 00
I know that is what those methods do. But how do I read the return if only 00’s are coming through? Iow, how do I code how to read that response?
I tried this:
void setup(){
Serial.begin(38400);
mySerial.begin(38400);
}
void loop() {
SendResetCmd();
delay(4000);
byte a[32];
counter=0;
//while(mySerial.available()>0)
//{
incomingbyte=mySerial.read();
a[counter]=incomingbyte;
Serial.println(a[counter],HEX);
counter++;
}
I get FF’s all the way. In Coolterm I can see the HEX and they are: 46 0D 0A 46 …
I get FF’s all the way.
No surprise there. You have commented out the line that checks whether any data are actually available to be read, then you read the nonexistent data anyway.
Thats because I was told to look for the init end response from the camera. I apologize, here is what I got from the CoolTerm app:
Thats as soon as I plug in the camera. But Im not sure what those first values saying? I can see they are different from the others which do represent FF.
How frequent do those FF’s appear now? Every 4 seconds perhaps? That’s because it keeps printing only the very first byte in the a byte array, that happens to be hexadecimal FF, every run through the loop. The 0D 0A is because you are using println, which sends a linefeed and carriage return (“Enter”)at the end. Instead of printing a byte from that array, why not just send what’s in the variable incomingbyte? With serial.print(incomingbyte,HEX).
If you didn’t put the double slashes in front of while and the { right behind it then it would also print out the rest until there are no bytes available in the serial buffer anymore. BUT, you would also be lacking a closing }-bracket at the end of the loop function. Make sure those add up evenly.
Why it is 0xFF (or 0x00 in the other attempts) is indeed a mystery. That value is not part of the response sequence of the command. The way I interpret that code snippet is the following: Each run through loop the SendResetCmd is executed ( I presume this sends 0x56 0x00 0x26 0x00 like the other code) Then it waits 4 seconds, presumable long enough for the response to be stored in the remaining space in the myserial buffer by the arduino. Then a byte array “a” is declared, and counter is set to 0. Then a byte is taken from the myserial buffer and the value stored in incomingbyte. Incomingbyte is then copied into the 0-th element of the byte array. That same element is then printed to the hardware serial port with linefeed and carriage return symbol. And counter is incremented for no reason, as it will be set to 0 the next round again. And the loop restarts. Where another SendResetCmd is issued, and potentially the response is added to the myserial buffer if received. And the oldest byte from the myserial buffer is placed into incomingbyte.
Effectively this prints new 1 byte from the myserial buffer every 4 seconds to the hardware serial port and computer. That’s a very slow serial bridge between the camera and computer, but essentially functional to monitor what is sent. If the camera responds correctly to the command then it is unlikely that every byte is the same. So my guess based on all of this is that the camera is not communicating back, or the message is lost along the way, or it is defective or not turned on.
So, let’s check the hardware electronic side of things, and leave the code be for the moment. This should probably have been adressed in the very first reply in these threads. How is the camera connected to the Arduino? And how is it powered? Pictures of the parts, pictures of the wiring, schematic of how you have it set up … proof of how YOU have it connected, not how somebody else in a tutorial describes it.
In the other thread I suggested to leave out the code on the arduino and send commands directly manually with just a serial terminal program. If you don’t have a usb-to-serial cable then this isn’t possible. I suggest you do get one. (Very useful so you can eavesdrop on the camera’s TX line with the computer. Software recording of serial data becomes tricky at high baudrates like this.) As you have used coolterm now, here’s how to send the command manually. It too can send specific byte values specified in hexadecimal values. See this Sparkfun tutorial at the end.
https://learn.sparkfun.com/tutorials/te … -mac-linux
If the camera responds properly then the response of the camera should also be seen in the output window.
Thanks,
Ok so:
- The diagram I followed originally is this one:
https://www.flickr.com/photos/43666730@ … res/67N9L1
and my connection looked like this:
https://www.flickr.com/photos/43666730@ … res/rPg79P
-
I dont have a usb-serial cable so I will try to get one today.
-
You say that the incomingbyte should be printed directly…ok sure, I can do that. Ive added it in order to compare, just for my benefit.
-
You say if I commented out the while{>0} block I should get the rest. The rest of bytes I presume. Im guessing there could also be - values then? Im not sure what is coming in the serial. At one point I saw a “-1” come through. That while {>0} block only prints out the values >0. What else could there be?
-
Following your interpretation, yes after 4 seconds after sending the command any incoming data is stored to a buffer by the arduino for further “dumping” into the serial port?
-
After declaring the byte array, 1 byte is taken from the buffer and put into the incomingbyte variable. Im not sure what makes it take only 1 byte at a time?
-
Yes the first byte is stored to the 0-th element because counter=0, but … OH!!! Duh! I reset to 0 each time because counter is set to 0 inside the loop. It worked in the manufacturer code because they reset j (their value of my counter) to 0 each beginning of the EndFlag while{} block, right?
I definitely need to work on the code. 
1: Can you get a better angle on the wires connected to the right side of the arduino? It is not clear where the purple/orange and grey/green wires are going into.
3: “Should” is a big word. It would avoid the potential of printing erroneous data if you used the wrong index value in the array. In this case you know for sure that incomingbyte has the oldest byte in thebuffer because it was assigned to it right before.
4: No, read more clearly what I wrote. If you DIDN’T comment out then it would print out what remains in the myserial buffer. The code you showed above does comment out the while-statement with it’s condition, but leaves the tail of it intact. (aside from the missing “}” ) So that is only executed once per loop.
while (serial.available()>0) {
// .... do this code
}
Read up on how the while loop is structured. Between the round brackets is the logical condition that determines if the code of the while loop should be exexuted. The function mySerial.available() returns the number of bytes left in the mySerial buffer. If it returns 0 [edit: actually -1]then it is empty. If there are bytes left then it is larger than 0. Thus the code behind the while-loop keeps running until the buffer becomes empty. Then it starts executing what comes behind the closing } bracket.
Hmm, I just realized something when looking up softwareserial.read on the arduino wiki:
https://www.arduino.cc/en/Reference/SoftwareSerialRead
Returns
the character read, or -1 if none is available
Now a Byte, the type of numbers that serial.read returns, is supposed to be between 0 and 255 inclusive, or 0 to FF inclusive in hexadecimal. So a negative number is not possible with that number type. But in binary numbers a negative number is represented in what is known as two’s-complement method.
https://en.wikipedia.org/wiki/Two%27s_complement
And -1 would become represented as 255 decimal, or FF hexadecimal. So that explains the long strings of FF’s, there is no data in the myserial buffer left to read out. Or no new data is coming in from the camera.
5:
- Following your interpretation, yes after 4 seconds after sending the command any incoming data is stored to a buffer by the arduino for further “dumping” into the serial port?
I don’t understand what you are trying to say here. I don’t understand your question(mark). This reads like a confirmation of what I wrote.
- After declaring the byte array, 1 byte is taken from the buffer and put into the incomingbyte variable. Im not sure what makes it take only 1 byte at a time?
As explained in 4, you removed the while statement from the while-loop. So it only executes that code following it once, per run through loop().
- Yes the first byte is stored to the 0-th element because counter=0, but … OH!!! Duh! I reset to 0 each time because counter is set to 0 inside the loop. It worked in the manufacturer code because they reset j (their value of my counter) to 0 each beginning of the EndFlag while{} block, right?
Correct. The counter increment is just show-case. Byte from serial.read buffer gets put into a variable. The content of that variable is copied into a memory location (also a variable of sorts). Then content of the memory location is printed out to computer over hardware serial. That is what happens with the myserial data. But the buffer is not infinitly large. So it might overflow if enough data is comming in. But it doesn’t seem like it this is happening. (confirmed by what I wrote at the end of 4)
Is this the cable converter I would need?
I’ve simplified the connections as I mentioned before. Im just working with the camera and the arduino. I took out the microSD (TFT) shield. Here is the complete image:
And yes, I did make a mistake commenting out the first { of the while loop and not the second one. But that only happened in my post.
quique:
Is this the cable converter I would need?[attachment=0]image.jpg[/attachment]
The manual of the camera is not clear if it accepts the ±12 volt that the RS232 serial connector operates with. This is what the manual on the SParkfun producty page says about it:
- If the UART is RS232 level. If want to connected to MCU, please add a
level shifter or remove MAX232IC. RS232 level is used in the module
as the communication distance of raw UART cannot be longer than 1
meter.
I can’t make heads or tails out of this. Better to assume that the camera only accepts TTL serial signals on the RX and TX line so it doesn’t get damages. (or perhaps search around the net for what others used to communicate with it) So this one is better/safer I think:
quique:
I’ve simplified the connections as I mentioned before. Im just working with the camera and the arduino. I took out the microSD (TFT) shield. Here is the complete image:[attachment=0]IMG_6686.JPG[/attachment]
And yes, I did make a mistake commenting out the first { of the while loop and not the second one. But that only happened in my post.
Still not the right angle of view to see where the green and orange wire is stuck in.
But if I zoom far in enough it seems the orange wire is stuck in to pin 5 and the green one in pin 6. Is that correct?
Then, what is the SoftwareSerial mySerial( ?? , ??); statement you had in your last code? Because I’ve seen different ones in all the various forum threads you created.
Serial(5,6)
Would that serial converter work to connect directly to the camera? Should I buy it for testing purposes?
Didn’t I give a better suggestion in a message earlier?
The one you showed a picture of should only be used if you have a device that has the appropriate serial connector. It may damage your camera and Arduino uno if you hardwire pins to it.
Serial(5,6) or mySerial(5,6)?
mySerial(5,6). I just wrote serial for short.
OK I’ll look for that product here. I’m in Honduras you see and it may not be available here
I’ll look for it today.
Thanks.
As I suspected. They dont have it here. Ive called about 4 different stores and they dont have it. So if thats the only route, Ill have to wait til I get it from the US somehow. 