Can you describe in more detail the issue with Switch 5? It is a problem specifying the switch function in INI Creator? Or does that part work but the function doesn't trigger correctly on the sound card itself? Can you also post your INI file? I will think about the engine speed request. All that sort of thing is possible with the TCB but the configuration framework on this device is much more simple as you can see (no dynamic allocation of functions with triggers). In the meantime, if you are using a programmable transmitter you can accomplish what you propose with a transmitter mix. But it depends on your transmitter, it is true that most pistol-grip car radios do not have that level of programmability.
Thanks. I see now the forum would not allow posting .ini files, I have changed that for anyone in the future who needs to attach one. Anyway, here again we have another bug which I have fixed, and you will need to flash new firmware (v0.93.51). Very few people in the world have even tested one of these sound cards, and I think even of those few people they are all using it with with the TCB - in other words, not in RC mode as you are. Therefore I am not surprised you are finding some bugs. I do appreciate your testing which is helping me perfect the firmware. Let me know if you notice anything else strange!
I have not personally designed a DIY Teensy board myself, so I can't speak from experience. But looking at the schematic I see no reason why separating the bootloader chip onto its own board wouldn't work (in other words, I think it should work fine). The only way to know will be to test. Of course you can also get some very good advice at the PJRC forum. They have a whole section called "Project Guidance" where you can describe your project and ask for input. There have been several threads in the past about people designing their own Teensy-compatible boards and the usual response is that it's not worth the effort especially for low production numbers. But everyone has their own idea about what efforts are worth making. If you have the time and the ability, as it seems you do, then it could be a rewarding experience.
There is a lot of forum spam going on (as I know from here), but hopefully they will respond to your message and allow you in. May I ask what country are you located in? I am interested to know all the countries that Open Panzer users are from.
Hi Luckowner, thanks for bringing those threads to my attention. It seems some progress has been made on the PJRC forums with sound sampling, although I see for now it only works with RAW files. It would be ideal if Paul from PJRC can include this feature into his official Audio library, and maybe he will be able to do so eventually. Unfortunately I have no time at all for development right now, so I can not be of much help to you. You seem to have come quite far already, I think if you stare at the code long enough you can see what I have done and probably figure out how to make the changes you need. Start small, make one change at at time and test, and through slow experimentation my experience is that you can eventually go quite far. I'm sorry I can't be of more assistance, but I wish you good luck and please let us know if you have success!
struct DataSentence { uint8_t Address = 0; uint8_t Command = 0; uint8_t Value = 0; uint8_t Modifier = 0; uint8_t Checksum = 0; };
The protocol is quite simple, for the sound card each "sentence" consists of 5 bytes: Code: [Select] struct DataSentence { uint8_t Address = 0; uint8_t Command = 0; uint8_t Value = 0; uint8_t Modifier = 0; uint8_t Checksum = 0; };You can see how the bytes are unpacked on the Serial tab of the Sound Card firmware. Commands are defined in the SoundCard.h file. On the TCB side you can see the mapping between TCB functions and Sound Card commands in OP_Sound.h and you can see the very simple functions for sending the sentence over the serial port in OPSoundCard.cpp.The process is basically the same for communicating with the Scout and Sabertooth serial controllers, except those use 4 byte sentences (Address, Command, Value, Checksum) - they don't have the "Modifier" byte. The Address is unique to each device and prevents the Sabertooth from responding to commands for the sound card, or the sound card responding to commands for the Scout, etc... The addresses are hardcoded, here is the current list: Pololu Drive - 10 (0x0A)Pololu Turret - 13 (0x0D)Sabertooth Drive - 128 (0x80)Scout Drive - 131 (0x83)Scout Turret - 132 (0x84)Sabertooth Turret - 135 (0x87)OP Sound Card - 218 (0xDA)If you are just re-creating the sound card where the only difference is the way acceleration/deceleration is handled, just give your device the same address as the OP Sound Card (218). In other words, this is simply an exercise in modifying the existing OP Sound Card firmware, as you have already discussed. If you are creating a device with all kinds of new features, you will have to give it a different address and then define your commands to do whatever you want (value and modifier are optional). However, I think the problem you will quickly run into is that you will want to issue commands that the TCB doesn't have and doesn't know about (in other words, new Functions). Adding new functions to the TCB requires not only changes to TCB firmware but also changes to OP Config, changes to the wiki, etc, etc... So that I am probably not going to do. You may find yourself creating a whole new TCB, or maybe a whole new product entirely. Even so, I hope looking at the code from this project will be useful to you.