Also, on the PCB of a genuine Syma 107, there should be “S107”* on the board (mine is printed with “S107R5”).
Another difference I’ve read about, and verified on my birds is that the genuine Syma 107 has a green LED on the back of the mainboard, which indicates communication status. On the fakes, the LED may be red, as shown below:
@ Architect
I haven’t posted the code yet. I’m close, but I still want to make a couple more tweaks. I had originally written the project using the built-in web server on the ethernet module, but that proved to have an issue with accepting the volume of requests being sent by the Kinect, so I switched over to UDP.
I just demoed the project yesterday to a local high school team participating in the next FIRST robotics competition (which now has Kinect as a potential tool for control/sensor, etc), and realized that I’m probably doing more work than needed on the Kinect project side, so I need to refactor some of that into the Gadgeteer project. One of the reasons is that in addition to the Kinect portion of the project, I’m planning to build a Windows Phone client to control the heli as well, so having the controller client be as thin as possible is an advantage there.
Would love to get some feedback conceptually on throttling the control commands, though. The Kinect pushes out 30 frames per second (on average) of skeletal tracking data, which is faster than the heli can accept commands. At the moment, I’m just counting in the Kinect project the mSec since the last command was sent, and only parsing the skeletal data and sending a command if that time has elapsed. I’d like to simplify and move that code into the Gadgeteer project, so that the controller project doesn’t have to know about it.
At the same time, the networking code in the Gadgeteer project is running in a while(true) loop, which as Kerry’s blog post points out, is a no-no in Gadgeteer land:
[url]http://blogs.msdn.com/b/net_gadgeteer/archive/2011/12/19/why-not-while-true.aspx[/url]
So I was thinking I could kill two birds with one stone by changing over to a timer-based setup in the Gadgeteer project, and set the timer interval to the period that the heli expects commands. My only concern is that I’m not sure whether additional UDP packets would get queued or discarded in this scenario. If they get queued, then I would rapidly lose any sync between control movements and the behavior of the heli, which would be bad. If they’re discarded, that’s probably OK.
Thoughts? Does the above seem like a reasonable idea?
It occurs to me that we probably should’ve started a new thread several posts ago. Perhaps too late now. ???
As the original author of this thread, you are hereby authorized to ramble on about whatever you like. This authorization is granted implicitly on all threads authored by same, and is henceforth known as the “SAY WHAT YOU THINK” clause.
If you haven’t already noticed, I do that all over the place here 
The only downside is it’s harder to find when searching later on.
I’ve Just Bought an amazing Hidden USB Digital Microscope with high quality options
ankaka.com/2-0MP-Hidden-USB-Digital-Microscope--4-LED-lights--30FPS--640x480-_p47789.html
Look at The highlights:
Powerful 200x Zoom
Extremely detailed images
2.0 megapixel image sensor
Record what your microscope is examining
Excellent wholesale price for resale market
Easy to use software for both professionals and amateurs
I’m really glad and I Hope That they provide some of those In the future
Sniff… sniff… smells like spam to me… :naughty:
I noticed also that they took the time to edit out the http link when they saw it blocked them. So spam, with intent. Is that first degree spam?
The device is real. So I guess it is just a very “on topic” attempt to advertise.
Well, the 1st post of someone should not be in Off Topic and shouldn’t be some kind of advertisement, I think.
So: smells like spam spirit 