The more I look at the datasheets, the more I think that Peter Betz's design which uses 2.5v might be the correct way to do it.
The larger "reference design" (dkwt32i) board we have uses 3.3V, and seems to run fine. The upper limit (datasheet) is 3.6V.
I was using 10k resistors instead of 5k's.
Yeah, I switched to 5K-ohm when actually wiring it up because there's a slight loss across the diode, and 5K-ohm worked so I never tried 10K-ohm.
I'm having trouble following the code changes in your example
That's a "unified diff", which is obtained with the "git diff" (or "diff -up") command. All you need to pay attention to are the lines beginning with plus/minus symbols. Delete anything with a minus, and insert anything with a plus. Done.
I don't yet know how github works for submissions either, and not sure I'll get to it soon.
My concern about your changes, the part I want to understand, is where you change "String &logMessage" to "const String &logMessage".
The use of "const" in a function parameter simply tells the compiler that the function will NOT be modifying the value of that parameter. So it is safe to pass both const and non-const values to it. Without "const", it really is a programming error to pass in a "const" value.
Do you think I should put all those flags into a separate configuration file that gets an #include?
My style would be to just have a single source file for this. More files is more hassle (eg. the new-ish "version.h"). Header (.h) files are only useful when there are multiple .c files that need the same declarations.
Configuration stuff like that should perhaps be placed as close as possible to the top of the file, to make it easy to find. Or at least that's how most projects I work with seem to have done it.
Also, unrelated, I have a separate #include file for the version number of the code but I'm having problems getting a pre-commit hook working which increases that number on every commit into GitHub. Anyone know how to do that?
Don't look at me.. I'm pretty stone age about this stuff!
Ah yes, I have noticed that if you leave that pin floating, the Arduino will randomly detect it as being "pressed" and you will occasionally have it restart the pairing process.
You can fix that by configuring it as INPUT_PULLUP, and then having the switch pull it to ground (through a resistor) instead of to +5V. Problem solved.
Interestingly, in your "internal-only" version, I predict you'll be implementing that as a Hijack menu entry instead of a physical button.
Yeah, I do plan to do that. But I also picked up a nice little panel-mount red button to use during development -- much easier than navigating menus. Couldn't find a similar blue button at the shop (Home Hardware in downtown Toronto).
My device lives in the trunk, so having an indicator LED for bluetooth connection isn't useful.
Now there's an idea.. I might have Hijack overlay a BT symbol onto the display when connected.. hmmmm...
Thanks again so much for all your help!
Likewise!
Previous Topic
Index
