Hi,
I’ve recently upgraded from a Cerberus to a Spider board, using the very same hardware modules & .NET VB program code - no modifications were required. However, once I play a specific note on the Tunes module, it plays it correctly, but then it continous with a low-frequency noise (sound)… Changing to another port does not stop this issue.
Public Const TuneTime As Integer = 50
Public Const MenuHome As Integer = 880
Piezo.Play(MenuHome, TuneTime)
When the program is started, there is no sound (noise) from the Tunes modules. Once the note is played, there is a continous noise present. Driving me crazy…
I use the latest software setup:
[ul]
VB Express 2012
MicroFramework 4.3 (QFE1)
NETMF and Gadgeteer Package 2014 R5
[/ul]
Hope somebody can enlighten me with this issue!
Many thanks in advance!
Kind regards,
Aubert
@ A_Dupont - Does the issue go away if you go back to the Cerberus?
Hi John,
To answer your question, I just made two projects (from scratch), one using the Tunes module on a Cerberus and one on the Spider. I made sure both hardware are up to date, see also:
[quote] Loader (TinyBooter) version information:
4.3.4.0 on this computer.
4.3.4.0 on this device.
The Loader (TinyBooter) is up to date. <<<
Firmware (TinyCLR) version information:
4.3.6.0 on this computer.
4.3.6.0 on this device.
The Firmware (TinyCLR) is up to date. <<<
Please wait for the device to reboot… Done.[/quote]
The project is using MFC 4.3 and the Tunes module is attached as shown in the attached image (showing the Spider board). The code I run is:
Imports GT = Gadgeteer
Imports GTM = Gadgeteer.Modules
Imports Gadgeteer.Modules.GHIElectronics
Namespace Tunes___Spider
Partial Public Class Program
Public Sub ProgramStarted()
tunes.Play(880, 50)
End Sub
End Class
End Namespace
The problem persists: the Cerberus setup makes a short “beep” (as expected), the Spider board makes the “beep” followed by a continous low-freq sound (which does not cure headaches ;D).
I also tried a different Tunes module and a “virgin” Spider board, both with the same results. Hence, to me, it seems as if the low-level library does not control the PWM output as expected on the Spider board (when used with the Tunes module).
Thanks,
Kind regards,
Aubert
@ A_Dupont - We will take a look and see if we can reproduce the issue.
@ A_Dupont - The issue should be fixed for the next SDK.
Hi John,
Ok, thank you.
Could you share the estimated release date for the next SDK?
Kind regards,
Aubert
@ A_Dupont - We do not have a firm date planned yet. If you want, you can work around this by downloading the fixed driver source at https://bitbucket.org/ghi_elect/gadgeteer/raw/0a3dd5081b0bcfc25d57c6e35663a91550eecbc1/Modules/GHIElectronics/Tunes/Tunes_43/Tunes_43.cs and adding it to your project instead of the Tunes reference. https://www.ghielectronics.com/docs/122/gadgeteer-driver-modification can help.
@ John - I’ve made a couple of additional updates to the tunes driver. What’s the best way to share those with you? I added a bunch more named notes in the Tones class, and made a couple of additional bug fixes (typo in Duration - “Durartion”) and a bug in the MusicNote constructor that incorrectly throws an exception on Timeout.Infinite as a duration value.
Pull request? Or just send you the updated code? I can also post to Codeshare, if that’s preferable.
@ devhammer - I also ran into that problem and my tunes driver source is posted with my Sheldon’s Theremin CodeShare project. I also added volume to the music note but noted (pun intended) that volume didn’t always work.
@ Duke Nukem - Yep. My fix was a little different in that I didn’t want to eliminate the check for negative values other than -1, but basically similar.
Regarding the volume, while it’s theoretically possible to get some volume control by varying the duty cycle, I don’t think that’s going to work at the extremes, because at very high or very low duty cycles, you’re no longer oscillating evenly. From a little digging around on Bing, it sounds like the better way to vary volume is to vary the voltage rather than the duty cycle.
Unfortunately, I don’t think there’s a way to do that with the Tunes module without hacking the hardware. Should be possible, in theory, with a breadboarded piezo and a variable resistor.
@ devhammer - I found I had better volume control at higher tones, but little to none at lower tones. It was just an attempt to see what I could squeeze out of that module as with a Theremin left side controls volume.
@ Duke Nukem - That sounds consistent with what I’d expect. From what I understand, each particular piezo will have a frequency range in which it is easiest to oscillate, and that’s probably the higher ranges where you can get some control over volume via duty cycle.
BTW - Crossing the threads, just in case you (or others) missed it:
https://www.ghielectronics.com/community/forum/topic?id=17849
Neat converter from RTTTL, plus a link to a bunch of RTTTL songs. I’m having trouble getting many of them to work without exceptions, but if I can work that out, it’s a much more succinct way of representing the notation than the way I’ve been doing it.
@ devhammer - We’re not set up to receive pull requests at this time, but you can always post or message me any bugs/improvements you find or come up with and we can take a look. I have fixed the two issues you mentioned for the next SDK, thanks.
@ John - OK, will do.
I hope that GHI will consider accepting contributions via pull request. Since you’re on a platform that would support it, doing so would allow you to leverage the enthusiasm of community members like Duke Nukem, who’s spent a considerable amount of time writing updated Gadgeteer drivers, but those will always be less discoverable than what’s in the box (so to speak).
That said, I understand that there’s a cost associated with dealing with community contributions via pull request, and you all know better than I do whether that cost makes sense for your business.
@ John - One other thing…I was not able to find any license info on GHI’s Bitbucket repo. That makes it really hard to share any updates the community might make. Although I trust GHI would be OK with sharing modifications of the code, without a license, many of us would be reluctant to publish any changes we make.
Any chance that GHI can choose a license and add it to the repo, so we know what’s OK and what isn’t?
@ devhammer - Pull requests are something we would like to support for our open source projects, but we have nothing specific planned at the moment.
We will get licensing information up on the repository soon.
@ John - Great. Thanks for the information.