Should have mentioned…already did that step on my other machine. Anyway, since I had not connected the board to the 2nd PC, it wouldn’t really matter in trying to reference the dll.
@ devhammer - I have been “binging” (we need a catchy verb here 
) the error message and it comes up a lot but I am not finding anything relevant for us here.
If I can offer an of the cuff suggestion, maybe it you run fuslogvw.exe we get lucky and see it is a .NET assembly resolution issue and it points us in the right direction. Failing that maybe use process monitor to capture the file load activity when the reference is added, I can do the same and we can compare the traces. I would be happy to do the investigation.
@ Architect - Man, that is a pretty picture. Beats my flashing lights and buzzing piezo any day I have been driving my wife insane with the incessant buzzing trying to tune the code…
Actually, I just figured it out, thanks to Bing, and this entry:
Although the issue in that case was related to ASP.NET, it included this very useful tidbit:
I had downloaded your ZIP to a file pretty deep within one of my Gadgeteer-related folders on Dropbox. So I figured it was worth moving the DLL to someplace nearer the root, and lo and behold, that fixed the issue I was having referencing the DLL. Go figure. 
1 Like
@ devhammer - Ah!!! excellent. Now we are all a little smarter, we are never going to get caught by that one again :wall: Thank you for your persistence!
@ devhammer
Good find!
@ taylorza Any other tests you want me to try?
@ Architect - Well, now that you ask I would be interested in knowing when the accuracy breaks down. So if the pulses are at 100ns, 500ns, 1000ns how accurate does it look. Also, it might be worth testing with the interrupts disabled.
@ taylorza - Well, now I’ve managed to find another bizarre issue. While I was able to reference the DLL by moving it, it looks like something in my project is holding onto the old path. Now when I reference the DLL in its new location, the “Full Path” property for the DLL points to the old location, so it complains it can’t find the .pe file when I try to build the project.
Bizarre!
UPDATE:
Actually, it looks like the full path is right, as it’s copying the DLL to the local Bin folder. Here’s the error I’m getting on build:
“Could not copy the file “[PATH_TO_PROJECT]\IRCommander_Hydra\bin\Debug\LE\dotnetwarrior.OSHW.Hardware.pe” because it was not found.”
I turned on “Show All Files” in Solution Explorer, and looks like the the dotnetwarrior.OSHW.Hardware.pe file is indeed missing.
Something special I need to do to get that to copy over?
@ devhammer - Have you tried deleting the bin/obj folders before adding the reference to the new location?
Yep, deleting will help for sure.
Interrupts enabled:
sg.SetBlocking(true, new uint[] { 100, 100, 100, 100, 100, 100, 100, 100, 100 }, 0, 9, 0, true);
Very accurate first pulse is 96ns, last is 98ns. The rest of them are 100 exaclty:
@ Architect - :dance:
Good stuff!
Bingo! That fixed the build problem.
Unfortunately, I’m not getting any response from the helicopter using the SignalGenerator class on Hydra. Nor am I seeing the same patterns visually (looking at the IR LEDs with my phone camera) that I see when running using OutputCompare on Spider under 4.1.
I may need to scope it to see what’s going on, but I’m wondering whether it’s not able to keep up with the 38khz carrier.
I’m not getting any errors from the SignalGenerator class calls, nor is the program crashing. Just not seeing the output I expect.
@ devhammer - It could very well be that the carrier is not able to keep-up. I did not ask @ Architect to test the carrier, to be honest I feel a little bad asking for all these tests.
@ Architect, if you do not mind could you please test the following
sg.SetBlocking(true, new uint[] { 5000000 }, 0, 3, 0, true, 38000);
If that does not work can you please test
sg.SetBlocking(true, new uint[] { 5000000 }, 0, 3, 0, true, 19000);
I am not sure if my carrier implementation is correct. Is it that while high the frequency oscillates at 38KHz and while low there is nothing?
[quote=“taylorza”]
I found the AT91SAM9RL64 (Hydra processor) quite challenging as the timers are very limited and I need to do a number of tricks to get the generator to perform reasonably well at relatively low frequencies.[/quote]
I thought about how implementing this for Cerberus. For non blocking generator, I found that completion feature is the simplest way to do it.
Look at HAL_COMPLETION::EnqueueTicks(): no timer to set, multiple signals is already handled.
Here’s what my SetBlocking call looks like, FYI:
SetBlocking(true, buffer, 0, buffer.Length, 100, true, 38170)
If I understand correctly, the way the carrier implementation should work is that the buffer that’s passed in should turn the output on at the carrier frequency when high, and off when low. So the carrier is effectively the “signal” being turned on or off based on the values in the buffer. That’s my understanding, anyway. Perhaps Architect can shed more light on it.
@ NicolasG - I will definitely take a look at that. Right now I am using a timer compare functions, but I found I needed to drop down to direct register access because the PAL/HAL layers have too much overhead to reach even the higher frequencies in the audible range without breaking down severely.
Thank you!
I think I understand, so basically, I should generate the carrier frequency for the duration, then during the On phases the carrier signal is sent to the pin and during the Off phase the pin remains low. Is that correct?
If so, I am definitely doing the wrong thing, I basically have a GerenatePulseTrain function which genrates pulses at a target frequency and then I activate that when the pin goes high and then deactivate it when the pin goes low. But, what you say makes more sense now that you have mentioned it.
3 should be 1 in the code above
Here is what it looks like:
each pulse is 12ns or 14ns (same for Low).
and the whole train was ~5s as specified.