Thanks so much for breadboarding it and trying it out!!!

Lots of information in your last few posts, I'll try to consolidate it all here in one post.


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. 3.3v seems more like the upper limit, with 2.5v being more like the nominal voltage. I think this bears out in my tests, where 3.3v makes the chip run real hot, but 2.5v runs cool.



I think that's the same as me, except that I was using 10k resistors instead of 5k's. This was my configuration:


Would the difference between 5k and 10k make the difference in this case? I'll try it and see if that fixes my issue.

Another idea that occurred to me, what if the problem was that I was doing too much voltage for the RST line instead of too little? What if my attempt to increase it to 3v from 2.5v was the wrong way round? I might try to bring it down a bit and see if that fixes it.



I went through several iterations of it, trying to fix my issue. It's likely that I put some stuff in as an experiment but which doesn't help.



OK, I will remove that. That was one of my experiments to try to solve my issue. My idea was that maybe the sensing logic on the chip's RST line needed a sharper transition than what I was giving it. But it didn't solve the issue, so you're right, I should remove that.



That was another experiment. I was having problems where the chip kept going back to sleep on its own when I would try to do things like pair up the bluetooth module. It would go into its pairing process and then fall asleep again. It was as if the act of a software reboot (the serial "RESET" command in the iWrap language) would put the chip back into sleep mode again. So every time I did a software reboot, also "pressing the ON button" every time seemed to fix it, at least for a while until I had the other problems come up.

If I can get the reset line working at all again, then I will experiment with putting it back to "just once at power on" again, like you originally had it, and see if it works correctly.



It doesn't have any problems compiling for me. There must be differences in the compilers we are using. I will make sure I'm updated to the latest Arduino compiler and make sure it's still working. Check to see if your version of the compiler is updated as well.



Thanks for that!

I'm having trouble following the code changes in your example, but I see that this is an opportunity for me to experience how GitHub works for managing external submissions. Would you be willing to submit that change as a pull request so that I could work with those features? I'm curious how things like permissions work. For instance, can anyone on the internet submit branch changes and then I choose which PR's to pull into Master, or can complete strangers commit directly to my Master? I'm really curious about this since this is my first time hosting a project on GitHub. Also, if you submit a PR, then I'll be able to see your changes in a graphical display and more clearly understand them.

My concern about your changes, the part I want to understand, is where you change "String &logMessage" to "const String &logMessage". My first instinct is that this shouldn't work because there are plenty of strings sent to the Log function set which aren't constants. So it needs to be able to handle all of them. I can't tell from looking at your BBS post how that's handled. So I want to see it in the GitHub comparison screen to understand it.



Thanks so much for literally risking your life for this project!



That's controlled by one of the flags at the top of the code:

It's possible that the one you tried was one of my tests with the I2S audio turned on.

In general, have a quick skim of the true/false flags at the top of the code before uploading the code.

Do you think I should put all those flags into a separate configuration file that gets an #include?

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? Googling isn't producing enough details for me to actually implement something in that area.



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. This is despite the debouncing code I've already got in there. The "button" on Pin 52 should have a pulldown resistor, to prevent the random floating thing from triggering unwanted pairings. From the README.txt:



Interestingly, in your "internal-only" version, I predict you'll be implementing that as a Hijack menu entry instead of a physical button. That will be cool. I'm curious to see what sorts of other UI information and messaging that you'll be implementing.

Right now my code doesn't attempt to detect when Bluetooth is considered "connected" or not. It merely responds to messages on the serial port as needed. I wonder if it should have a flag to try to keep track of that, so that you can display messages on the screen in your "internal-only" version like "Bluetooth connected" or something. Not sure if that would be useful to you or not. In my case I don't care, because my device lives in the trunk, so having an indicator LED for bluetooth connection isn't useful.

Thanks again so much for all your help!