another view
@ Architect - Thank you. It seems that the code is able to keep up with generating the frequency, to be honest, I am surprised.
So I see to issues
[ol]I might need to use a smaller divider for the clock because it looks like I am overshooting the frequency, going higher than the target frequency
I am probably handling the carrier incorrectly and should be doing it are per the description given by @ devhammer, which of course now seems silly that I did not do that in the first place.[/ol]
I will get cracking on this first thing tomorrow. It is getting a little late or early on this side of the world.
Thank you both @ Architect and @ Devhammer very much and I hope you will bare with me so that we can make this a usable offering.
Have a good night! Great work!
@ taylorza - A little bit more info for you. I looked closer to the collected data
with pulses variating betweeen 12ns and 14ns the period changes from 24ns to 26ns.
Which gives us 41.67kHz and 38.46kHz
@ taylorza - Following upā¦Iām in the process of finally developing a proper driver for my module (about time), so I just tested the driver on the FEZ Spider under NETMF/Gadgeteer 4.2, using the same code that I was trying to use to test your Hydra firmware.
Results were visually as expected (blinky IR LEDs), and properly operated the IR helicopter. So Iām pretty sure youāre right that your current implementation of the carrier frequency overlaid with the buffer of timings is incorrect.
Once youāve had a chance to post an updated version, Iāll give it another shot.
Then, the trick will be figuring out whether or not I can specify more than one required mainboard in the driver (GadgeteerHardware.xml allows you to specify additional required libraries, including mainboard drivers, but Iām not seeing any way to include more than one without ending up requiring both, rather than either).
This is a good case where we as a community need to see how a module can take advantage of non standard features. And maybe even involve the core team if necessary.
Looking forward to see where this goes in future.
I have uploaded a newer version of the Firmware
URL : Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
File : FEZHydra-SignalGenerator-0.2.3.zip
I have made two changes
- Increased the timer resolution which should help with overshooting the frequency
- Re-implemented the carrier algorithm to work as we discussed which now seems more logical
@ Architect, @ Devhammer - Thank you for the additional information, I hope this brings us a step closer to flying the copter with OSHW.
@ taylorza - So, first, a confessionā¦my earlier code may have been part of the problem, in that I was referencing the wrong socket. :wall:
That said, I just tested the new firmware, with the code pointing to the correct socketā¦andā¦
IT WORKS!!! 
In the initial test code, I was simply passing the module a single command string in a timer over and over, just to test that the helicopter would throttle up. Next, Iāll recreate the entire control rig (without the networking aspect for now), and make sure I can fly the heli via local control. I may also build a separate version of the IR LED Array Driver with a dependency on the Hydra driver and your managed library, and point to this thread in the error message if they arenāt there.
Thanks very much for thisā¦I know @ ianlee74 has been waiting ages to be able to play with the IR LED Array module I sent himā¦now he can. 
Awesome!
@ devhammer - That is excellent news! I was watching your video of the helicopter on your blog this mornings, it looks very cool.
Thank you again for all the effort you and @ Architect have put in to help with the testing. Your explanation of how the carrier works was key to the success.
Quite a small effort, compared with adding this functionality to the Hydra firmware (something Iād be completely lost attempting), but my pleasure! Once Iāve got the updated rig assembled, Iāll shoot a quick vid and pass it along. 
@ taylorza - Ah, progress, then stalling. Great pattern.
As noted, I was able to get the module working with the custom firmware, but Iām stalled on getting the Hydra version of the driver up and running, due to what appears to be a WiX error, for which I started a separate thread here:
http://www.tinyclr.com/forum/topic?id=10137
Any WiX gurus willing to take a look?
Meanwhile, will proceed with setting up a test rig without using the driver.
OK, test rig built, and all works as expected, as shown in the vid:
If I can figure out how to get the driver project for Hydra to build, Iāll be all set!
@ devhammer - Cool!
My wife had a good chuckle hearing you calling my be my forum nick.
LOL! Always good to keep the wife laughing.
Thanks for the reminder on the WiX issue to check path lengthā¦that turned out to be the problem.
@ taylorza - I will try new version later tonight and will post LA screenshots.
@ Architect - That will be great, thanks. Now I will start working on implementing multiple concurrent async signals. As I mentioned currently the generator only supports a single async generator, I guess this could be useful for generating multiple low frequency signals.
@ taylorza - I have tested the new firmware - it is accurate. I sampled at the highest rate of 24MHz on my LA and it shows very close to 38KHz.
@ Architect - That is great news. Thank you for your support and effort in testing this.
No problem. Let me know if you want to run any other tests.
I have just put up what I believe to be a feature complete version of the custom FEZ Hydra Firmware with SignalGenerator. The final piece was support for multiple concurrent async generators running.
URL : Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
File : FEZHydra-SignalGenerator-0.3.zip
Now I will start cleaning-up and commenting the code so that I can make it available on codeplex.
5 Likes