Hello
I am trying to test the Pixy UART connection
and I do not understand why I find a great number of $00 bytes between two good frames !
Is it possible to receive only the objects frame and to have an idle line between frames ?
Second problem: is it possible to send the parameters of signatures to Pixy by uart?
Thank’s
David Porteils
Hi David, there are some padding bytes sent between frames. SPI uses these, although it may be possible to remove these for UART…
You can’t send signatures to Pixy by UART — signatures a little statistical models that are not very easy to generate… what are you trying to do – maybe we can suggest a better solution.
thanks!
Hi David, there are some padding bytes sent between frames. SPI uses these, although it may be possible to remove these for UART…
You can’t send signatures to Pixy by UART — signatures a little statistical models that are not very easy to generate… what are you trying to do – maybe we can suggest a better solution.
thanks!
Hi Rich
thank you for your reply
I want to interface Pixy with the robot that I use with my students
I am using the UART for that, and I prefer to remove padding bytes to avoid generating unnecessary reception interrupts on my microcontroller
So how can i remove the padding bytes from the Pixy UART ?
and one last question : why the speed of the uart is limited to 230 kbps?
Best regards,
David
The 230 kbps baudrate is a practical limit — you can try faster baudrates up to 600kbaud I believe.
We’ll look into removing the padding bytes for the next release…
thanks!
Hello Rich
I test the UART communication with a picoscope up to 1 Mbaud and it’s OK
the problem is that when increasing the speed the number of padding bytes to 0 increases also, so now, it’s not interesting to increase speed
Now we start the software to interface Pixyto with our robot, is it possible to have a version of Pixy without UART padding bytes in the next days ?
best regards
David Porteils
Hello David,
We’ve added this to our fixes for this release and we’re doing the QA at this point. Hopefully it will be in the release for Friday.
Edward
thank you very much Edward
I hope you will not have any problems so I can test the new version
best regards
David
Hello David,
The new build is posted (2.0.6 PixyMon, 2.0.8 firmware) that removes the padding bytes. Download the PixyMon package which includes the new firmware. You’ll be asked if you want to upgrade your firmware when you run PixyMon.
http://cmucam.org/projects/cmucam5/wiki/Latest_release
Let us know how it goes!
Hello Edward
I did the update 2.0.6 PixyMon and 2.0.8 firmware, but there’s no change
there is always the padding bytes 0 !!!
I do the test with one object and UART at 115200 bauds
The Frame of the detected object is good and there is more than 200 $00 bytes before the next frame an so on …
I tested with PicoScope and RS232 Monitor (XCTU)
perhaps, it’s not the good version on the server ?
David
Hi David, give this firmware a try (attached).
Hello Rich and Edward
I was away for three days
I just tested the new version you sent me
This is perfect, the 0x0000 indicating a new frame or if a frame is empty
and after the déctected objects.
I tested from 115200 to 921600 baud
thank you very much
David Porteils
Hello,
I’ve been following this thread as I am using the UART interface as well.
I’m trying to figure out from the thread ALL the changes you made to the UART data frame. I like that you eliminated the extra zeroes between blocks, but it also appears that you changed the data block if no objects are present. Is that true?
My code is broken now, which I don’t mind if there are beneficial changes. I just need to know what they are so I can fix my code.
What is the format of a data frame now? Are there still two sync words or just one? What comes after that if there are no objects in the field of view?
Thanks.
MY BAD!
Sorry, I forgot that loading the new version would reset a bunch of parameters.
It’s all good once I set them back to the proper values.
Robert
OK, one more time…
I’m unclear by the comments above what data is sent by firmware v2.0.8 in UART Mode – +when there are no Objects in the FOV+.
Is data still sent every 20mSec (something that could be used as a heartbeat)?
If so, is the data an entire Image Frame with a sync word sent at the beginning of it?
If so, does the data include an entire Object Block with a sync word sent at the beginning of it?
i.e. How much of the sent data (if any) is zeroes – when there are no identified color objects present?
Thank you.
Hello
the firmware v2.0.8 send always padding bytes $00
the firmware without padding bytes is pixy_firmware.hex (267,06 ko) which is joined in the post of Rich Legrand 7 days ago
Best regards
OK, great! Thanks for your quick response, and letting me know the details about v2.0.8.
I see the other firmware version you are referring to. I’ve downloaded it.
However, that still leaves my questions…
+If there are no Objects in the FOV+, what data is sent in UART Mode (in the special, non-zero-padded firmware)?
I am not seeing sync words as I had hoped. Are they there and I’m just not seeing them?
Thank you for your attention.
Robert
Hello Robert
when there is no object
there is only 0x0000 every 20ms
look at the joined document
i put oscillogramme of the frame with 0, 1, 2 objects
David
Thank you David. (And thanks to Google translate to help me with the French I couldn’t figure out!) That helps a lot.
Just to be completely clear, let me restate what I believe to be true from your document:
So in summary…
What’s new is that there is a 0x0000 sync word every 20mSec, and if there are Objects they follow in the format of the old protocol.
Is that all correct?
Thank you very much for your time and the document.
Robert
it’s perfect !