1141

TCB Dev / Re: TCB - Radio Question

« on: January 21, 2017, 12:31:09 PM »

Bonjour Rebus! The TCB can read the radio signal from any receiver capable of outputting PPM, SBus, or iBus. It sounds like you have modified your radio so you have 8 distinct positions on a single RC channel. It is no problem for the TCB to read this, the hardware does not need to be changed.

However the TCB firmware right now is only written to handle inputs from RC channels that are either analog (stick or knob) or either a 2 position switch or 3 position switch. These are the types of controls commonly found on RC radios today. The firmware could be changed to read an 8-position switch but since almost no one has such a thing, it would be a feature with very low priority and you would have to add it yourself.

You took the approach of combining many functions into a single channel. I can understand why you did so, because in the past receivers and tank controllers can not handle many channels. The TCB is different, it has no problem reading 16 channels. Therefore a better approach will be to obtain a radio with many channels and many switches.

Since you are comfortable modifying your transmitter, you might consider something like the AR9X upgrade board in a Turnigy 9X (not 9XR). The AR9X lets you add additional controls including pushbuttons if you prefer buttons to switches.

1142

TCB Dev / Re: Getting Started

« on: January 20, 2017, 10:34:17 AM »

It's been over a year since I went through all this myself but I do remember it seemed much harder than it really should be to get Qt working. I think we took a different approach but there are probably a hundred ways to skin this cat. To be honest I found documentation to be one of the weak points of the Qt ecosystem, especially in this topic, and they have download links spread out all over their site for different things, and different ways of actually getting their software, which makes it very confusing.

What I ended up using was their Online Installer. It may not (probably will not) actually download exactly what you want the first time, but you can always run the tool again afterwards, select "Add or Remove Components" and install the pieces it missed. Most notably I seem to recall the default compiler was MSVC and what I really wanted was the MinGW compiler, but this was easy to add.

In the screenshots below you can see I actually have Qt 5.4 and 5.6 installed, with the MinGW compiler for both (I also still have the MSVC compiler for 5.4 which I don't need). From within Qt Creator (not the same thing as Qt), I can select which Kit to use and I am able to for 5.6 if I want, but due to the above mentioned issues I've kept it at 5.4 for now (5.4 was the latest release back when I started this project).

Anyway thanks Marc for posting a step-by-step guide. If you can think of something that would make it easier for others to get going let me know. Maybe different arrangement of the files on GitHub, I don't know. What's on GitHub does reflect exactly my own project directory.

I kind of try not even to think about Qt installation and had mostly been happy to forget that chapter in my life... I take images of my C: drive at routine intervals precisely so if my computer crashes I don't have to re-install this thing a second time.

1143

Open Source Sound Dev / Re: Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 18, 2017, 11:29:44 PM »

I was able to do some testing. Using the optimized Teensyduino SD library for reading SD cards instead of the Arduino library, and using a SanDisk Ultra card which has "higher non sequential speed" according to PJRC, I was able to stream 4 stereo WAV files simultaneously without problem. Perhaps I could do even more but that's as far as I tried, and it should be plenty for what we need.

Using a slower card (Kingston brand) I could only reliably get 2 stereo sounds simultaneously, so the card definitely makes a difference. However even the Kingston was able to stream 4 mono files.

I could detect no difference in performance between audio out via I2S or DAC, which is what I expected. To keep the hardware simple I'm going to proceed with DAC out to a mono amp for now. We can always change the hardware later if we need a stereo version, the firmware is going to be the valuable part, not the board.

I've attached a picture of the hardware I'm using now: on the bottom is a simple carrier board, followed by a Prop Shield, then a Teensy 3.2, then an SD card shield. It's kind of a hot mess.

Feeling comfortable this setup will give us the technical capabilities we need, I will next design a better carrier board to eliminate everything but the Teensy. It will consist of the SD card slot, amplifier, speaker and volume connections, RC and TCB connections, etc...  I might throw on a small flash chip as well.

Of course the firmware is the most important part. I'll try to have some code in good enough shape to start a GitHub repo within a few weeks. Perhaps ninety percent of the functionality will not be difficult other than putting in the time. The challenging part will be realistic engine speed routines. That is the part I expect the more people involved, the better the outcome.

1144

Other Open Source Projects / Hardware Notes

« on: January 18, 2017, 08:19:59 PM »

Hardware Notes

Included in the project files (and attached below) is a simple schematic in PDF format, please review it for wiring details. An Arduino Nano is shown but the pins are the same for the Uno.

To trigger the cannon fire:

• Manually - connect a pushbutton between Arduino pin D4 and ground.
• From some other device - send a 5v input signal to Arduino pin A0. Voltages greater than 5v can also be accepted, but you will need to pass it through a voltage divider first (two resistors). NOTE: Whether you use this input or not, it should still also have a resistor added between pin A0 and ground, otherwise you will experience random firing. See the attached schematic PDF.
• Automatically send repair signal when hit received - in the A_Setup.h file in the Arduino IDE, set both REPAIR_TANK and REPAIR_ON_HIT to "true". Any time a hit is received, a repair signal will be returned.

"Apple" (IR receiver)
You can connect a standard Tamiya "apple" directly to your Arduino (Tamiya 53447). The Tamiya apple combines an IR receiver and notification LEDs; the LEDs already have current limiting resistors included inside the apple.

If you want to build your own IR receiver and use your own hit notification LEDs, you need to include your own current limiting resistor appropriate to the notification LEDs you choose. Most Arduinos can't source more than 40mA per pin.


IR Emitter
For the IR transmitter you can use the Tamiya IR LED that is included with the Tamiya apple, or a Taigen/Heng Long IR LED.

We have also found the Vishay TSAL6100 (DigiKey 751-1203-ND) to be a comparable replacement to the Tamiya.

For maximum distance the IR LED needs to be driven far beyond its typical current rating, but even so it still needs a current limiting resistor. The LED will survive the high current because the IR signal is very brief. In testing we have found a 3.3 ohm, 1 watt resistor to be the best compromise between range and LED longevity.

If you wish to send repair signals it is often desired to prevent the beam from traveling very far. In this case a higher value resistor is used inline with the IR emitter - we have found 1k ohm will give you a range of just a few feet.


Recoil Servo
Attach the signal wire of your recoil servo to Arduino pin D8. The servo will perform a recoil effect movement when the cannon is fired. Recoil servo adjustments (end points, reverse, retract and return times) can be set using the options at the top of the A_Setup.h file.


Taigen or similar Flash unit
A Taigen cannon flash unit can be used and will be flashed when the cannon is fired. Connect the flash signal wire to Arduino pin D6.


Sound
Up to 4 sounds can be added with the use of an Adafruit "Audio FX" board. They have several versions, you will want to use the ones with a built-in amplifer. They have a 2 MB version and a 16 MB version.

These are the four sounds that can be played, add them to your Audio board with these names:
T01.wav - cannon fire sound
T02.wav - cannon "hit" sound
T03.wav - destroyed sound (device has received enough hits to be destroyed)
T04.wav - repair sound

These sounds will play when the cannon is fired, a cannon hit is received, the vehicle is destroyed, or a repair operation occurs, respectively.

Connect your Audio FX board trigger pins to your Arduino like so:
Audio FX Trigger Pin 1 > Arduino pin A1
Audio FX Trigger Pin 2 > Arduino pin A2
Audio FX Trigger Pin 3 > Arduino pin A3
Audio FX Trigger Pin 4 > Arduino pin A4

You don't have to add all four sounds if you don't want. Also make sure the Audio board and your Arduino share a common Ground connection, and of course both have power.

Here is Adafruit's tutorial on these boards for more information.


Firmware Notes

Compiling Firmware
The Arduino project has made and continues to make all sorts of changes to their compiler, and unfortunately this can sometimes cause problems, and this proejct is one of those cases. The code will compile but will not always be stable or operational. If a non-compatible version of the Arduino IDE is used, the most common sign that problems will occur is if you see see a compile message to the effect that "global memory usage is over 90%," with the warning "Low memory available, stability problems may occur." And indeed, stability problems will occur.

Here is the workaround:

Load this project in the Arduino IDE. Go to the Tools menu -> Board -> Arduino AVR Boards -> select "Arduino Nano". Note that this will still work with a UNO even though you select Nano.

Now once again go to the Tools menu and select Board -> Boards Manager. Wait for the Boards information to load, then find the "Arduino AVR Boards" section. Click the "Select Version" drop-down box and select version 1.6.20 (not 1.6.2) and then click Install. After installation has completed, click Close to close the Boards Manager, and then compile.

The compiled code size should show global memory usage somewhere in the 70% range with no warning about instability problems.


Firmware Settings
Within the sketch is a file called "A_Setup.h" (it will appear as a tab in your Arduino editor). That is where all user settings can be adjusted. Recoil servo, IR protocol selection, "weight class" and other settings are defined here. There are extensive notes in this file so just read through it and it should be self-explanatory. 


Troubleshooting
Leave your Arduino attached to your computer with a USB cable and open the Serial Monitor from within the Arduino IDE to see informational messages printed during operation.

1145

Other Open Source Projects / Standalone Tank IR

« on: January 18, 2017, 08:18:27 PM »

For the fun of it I've taken some code from the TCB having to do with IR, simplified it and packaged it as a self-contained sketch for running on any Arduino Uno/Nano/or other board with ATmega328 processor.

The sketch can be downloaded here: TankIR

What does it do? Basically it lets you send and receive tank IR signals. All common protocols are supported: Tamiya (1/16 and 1/35), Taigen (old and new), Heng Long, and others.

Sending (ie, "firing the cannon") can be triggered in three ways:

• Manually with a pushbutton
• With a positive 5 volt trigger from some other circuit
• Or the device can automatically fire a repair IR signal in response to being fired at by some other tank (useful as an "automatic tank repair station.")

The sketch can also control a recoil servo which will articulate whenever the cannon is fired. A Taigen muzzle flash unit can be attached, and basic sounds can also be added with an inexpensive Adafruit Audio FX board.

The next post will go into more detail.

1146

Other Open Source Projects / Re: StabiWii Turret Stabilization by Squirlier

« on: January 16, 2017, 08:34:33 PM »

Mitch, the mention of programming a tank to follow a route and the like brings to mind the APM Rover project, in case you are anyone else is not familiar with it. This is the "ground" variant of the popular ArduPilot project. Ironically in the early days they were running this on the equivalent of the Arduino Mega 2560, which in no small part inspired me to use that processor on the TCB. Their firmware has since graduated to more powerful processors; details are at the Rover site. All of their firmware is open source.

The APM project is quite mature now. They have full featured groundstation software (perhaps more than one to choose from last I checked), and every possible autonomous ability you may wish. APM Rover has won AVC numerous times. 

Not that you were necessarily thinking this, but for other people who may come here wanting to embark on autonomous tank projects, you will reach your goals much faster with Rover than by trying to build upon the TCB, which is really geared towards RC control at this point.

1147

TCB Dev / Re: Getting Started

« on: January 16, 2017, 07:57:41 PM »

I'd kind of forgotten a lot of this stuff myself and hadn't ever expected anyone to set up a Qt environment, which explains why my installation notes are non-existent. You've gotten 99% of the way there with no help, in just a few days! It took me weeks just to get to where you're at now.

• I don't ever remember having to do anything with vcvarsall.bat, but perhaps we are using a slightly different IDE
• Yes, this is something I hadn't thought of. What you need to do is copy a few files from the assistant subfolder of your installation directory (the directory created when you install OP Config normally, probably in Program Files somewhere) to the assistant subfolder of your active build folder (the folder that gets populated with a compiled version of OP Config when you build from the IDE). In my case, the build folder looks something like:
  ...\QT_PROJECT_DIR\build-OpenPanzerConfig-Desktop_Qt_5_4_2_MinGW_32bit-Release\release\
  Within that folder create a subfolder called assistant and copy into it assistant.exe and the help_files subfolder from the assistant folder in your OP Config install directory.
  Clear as mud??
• Sounds like you got this one sorted out.

As for the highlighting issue in the sidebar menus - this is a known issue with Qt 5.6. I posted an issue here almost a year ago but I seriously doubt anyone is going to address it (they are probably waiting for me to solve it). So if you are compiling with 5.6 that may explain what you see. There is a workaround in the source but it's commented out (do a search in the project for "changeStackedWidget56Fix").

The other thing 5.6 does is deprecate elements needed to run the Assistant application. Last time I looked there was no good replacement. Since i kind of liked the help files within the program (even though they are all available online too), I've stayed with Qt 5.4 for now.

I am using Qt Creator 3.6.1 as my IDE and MinGW 4.9.1 as the complier. If you select Qt in your Windows "Add or Remove Programs" (or "Programs and Features" as they call it in new versions), right click and select "Change", the MinGW compiler should be one of the components you can install. But if you are using a different IDE than Creator then this won't be much help.

In Qt Creator you can build your project using different "Kits" and perhaps you are compiling with Visual Studio or something which may explain some of the differences we seem to have. I tried at one time compiling with Microsoft Visual C++ (MSVC) but never got it to work for some reasons I don't recall.

I don't know if any of this is useful or not, just thought I'd throw it all out there.

1148

Open Source Sound Dev / Re: Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 16, 2017, 02:26:31 PM »

Those are some good thoughts vonT and no suggestion is a dumb one! At least if it gets us thinking. It may have been a long time since you did work in audio, but for me it is all completely new. So I know very little but have learned enough to realize this is an extremely complicated subject, which probably explains why a good sound system for models is so hard to find.

But my design philosophy generally is not to add a feature that would be useful for the 10 percent if it inconveniences the 90 percent. If it can be added without inconvenience to those who don't use, then ok. But in the case of a sound card with stereo outputs, users would then have to use two speakers or a special stereo speaker, which I imagine is hard to find in the small sizes we typically require (at least in 1/16 scale). It may be possible to design the board with two amps, each fed stereo but one that converts to mono and one to stereo. This increases board size and cost. I suppose another option would be to proceed with an amplified mono output but have stereo line-outs available for those who want it, and they would need to supply their own amplifier.

Using each individual channel for overlapping sounds is a good idea, but so far as I can think ahead, doesn't solve any technical issues regarding read limitations on SD cards. We can't start or stop reading the left and right channels of a given audio file at different times, they have to be streamed simultaneously - but we don't know for example when the user is going to want to fire the cannon relative to the position of any engine sound, so pre-mixing overlaid tracks is not going to help us much.

Maybe there are some other benefits I'm not seeing or comprehending...

I think with the correct SD card we should be able to play three sounds simultaneously - or at the very least two. This is not as great as it seems since we will need at least two just for engine sounds (the engine being dynamic we will constantly be fading from one sound to the next, which requires two tracks to overlap each other for at least a portion of time). But if we can reliably get three I think we are out of the woods.

It may also be possible to put short sounds like cannon and machine gun fire, squeaks, etc... in flash memory. If there is space to pre-load all the variants likely to be required, these could be static and therefore wouldn't require the complicated end-user hassle needed to get those files onto the flash, but would still let us stream more sounds simultaneously.

Anyway, these are my random thoughts for now...

1149

Other Open Source Projects / Re: StabiWii Turret Stabilization by Squirlier

« on: January 16, 2017, 01:56:43 PM »

Ok, so that's as far as I got. There are other priorities right now with TCB development so it's unlikely I'm going to have the time to pursue this system further, but maybe it will help others get started, as well as have a place to share notes, etc...

1150

Other Open Source Projects / StabiWii Turret Stabilization by Squirlier

« on: January 16, 2017, 01:48:26 PM »

Some users at RCU pointed me to Squirlier's (Christian S.) open source StabiWii project. I thought it might be good to have a place to discuss his project (in English) for those interested to experiment with it. Just to be clear, I don't know Squirlier nor have I worked on his project at all. I am not a developer on his project and I take no credit for any of the work done!

Here are his shared project files: StabiWii at Google Drive
Here is is YouTube page: Squirlier YouTube

As of today the TCB does not have barrel or turret stabilization features enabled. I have worked on it but not reached a functional stage. As I think about it more, I have begun to think a different approach might be best - implement a small microcontroller and sensor board that takes care of all the stabilization functions, and simply plugs inline with the servo/motor signals to the turret. In other words, offload all stabilization work from the TCB into a standalone device that could be used with any tank control system or RC radio.

As it turns out, that is precisely what the the StabiWii does. It does not need to be integrated with the TCB and it could be used in any RC tank regardless of MFU. That is why I have put this thread here in the Other Open Source Projects forum.

From my preliminary investigation, the StabiWii project is a modification of the MultiWii Project. MutliWii has a long history and originally began by using the sensors in the Wii Motion Plus controller paired with an Arduino Nano and community code to control a quadcopter. The StabiWii firmware appears to be designed to run on either a NanoWii Flight Controller (available from Hobby King and perhaps elsewhere), or just a standard Arduino Nano paired with an MPU6050 IMU (both of which could be purchased from SparkFun).

The NanoWii FC has a lot of other features and functions that wouldn't be needed for turret stabilization, and the code is fairly complex as a result. Documentation at this stage appears to be fairly poor, as well as a lot of it being in German. I'm not critiquing the project at all, just stating my observations. It also does not appear that the project has quite yet reached final completion to judge from Squirlier's latest video, although what he has accomplished already is very impressive!

I don't have a NanoWii to play with, but I did download his firmware and it compiled just fine in the Arduino IDE. I was also able to get his GUI configuration program to run, but I have no idea how to use it.

His Google Drive site is a bit confusing, but here is what I downloaded:

• Go to StabiWii-Beta folder
• Download three packages:
• jre-7u79-windows-i586.exe
• StabiWii - TankConf V26.rar
• StabiWII -32u4-328P---V26.rar
• The .exe file will install Java Runtime Environment which is needed to use the Configuration program
• Un-rar the other two packages, I used 7-Zip
• The "StabiWii - TankConf V26" is the GUI configuration program. Although I am using Windows 7 x64, I wasn't able to get the "application.windows64" version to run, but the "application.windows32" did work fine. I see also a "StabiWiiTANKConf.pde" file in this folder, I don't know if you have to load that sketch on to your NanoWii in order for it to be configured or not? Unclear.
• The "StabiWii -32u4-328P---V26" is the Arduino firmware for the NanoWii. It compiled for me without errors in Arduino IDE 1.8.1 by selecting "Arduino Nano" as the target board.

1151

Open Source Sound Dev / Re: Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 15, 2017, 04:16:15 PM »

What I need to do next is determine if using the Teensy's onboard DAC in any way causes more problems with simultaneous SD card reads than outputting I2S only. I don't think it will but I have not gotten far enough in my experiments to be sure. If there is no real difference, then I think I will design a board that uses the Teensy's onboard DAC fed into a Class D amp and that should be all we need for hardware. If I find I2S somehow appears to give us a bit more wiggle room, then the hardware will probably use the MAX98357A listed before.

One thing I need is a quality set of sound files for testing. The Benedini comes with good sounds but they are in proprietary format. I've assembled a small set of my own for playing around with but I put no effort into them and they sound awful to begin with, so they will continue to sound awful no matter how wonderful this sound card may or may not become. I know there are a couple guys on RCU who have have really gone all in creating quality sets for their models, I may ask over there if anyone wants to share.

1152

Open Source Sound Dev / Re: Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 15, 2017, 04:07:10 PM »

Now we need to think about the audio source, SD card or flash memory. From an end-user perspective, an SD card is to be preferred by far. Put your files on it, stick it in your sound card, bam, you're done. SD cards are cheap and can provide gigabytes more storage space than we'd ever need.

Here is the big downside to SD cards - they are optimized for reading serial data, not parallel. This means you can stream a song off it no problem, but try to stream two sounds, or three, or more simultaneously and the card quickly croaks. The processor on the Teensy is more than capable of managing probably even a dozen simultaneous audio streams, but the SD card will not be able to keep up.

This is why the RC Tanks Australia Asp2 board uses two SD cards to play two sounds simultaneously. There is nothing special about the sound cards, they are off-the-shelf Chinese mini MP3 modules that are awash on eBay. On the first MP3 player he has engine sounds running, on the second auxiliary sounds like cannon fire. This works (if you don't need more than 2 sounds) but is bulky, inflexible, unsophisticated and not the way I want to go.

Putting sounds on flash memory solves the polyphony problem, but creates many more. Small flash chips don't have great capacity, in 8-SOIC packages I think the limit now is about 16 Mbytes. Considering the Audio Library only plays 16 bit, 44.1 kHz WAV files, this isn't much. Getting flies on to the flash chip is also a royal pain. The user can't simply drag and drop files the way they can with an SD card. We need to add functionality to a PC application (OP Config) to convert and load them, and bother with a bunch of extra hassle on the controller as well.

When you realize the complexity of this approach you really start to appreciate the genius of the Benedini TBS which runs on a ridiculously humble 8-bit ATmega168 processor with only 3/4 MB of flash memory to store sounds!! This is the extreme opposite approach to the Asp2 board. Thomas makes up completely what he lacks in hardware with pure brain power and sophistication typical of the Germanic race.

However I am no Thomas. It would be great to have him design a board for us but then he'd put himself out of business. So we shall have to muddle ahead ourselves (or myself).

In the end I think there is no avoiding the use of an SD card, the benefits are just too great. We actually can play more than one sound at a time from SD, but we have to be careful how we do it. And there is no guarantee I won't run into some pitfalls that make all this effort a waste of time eventually.

1153

Open Source Sound Dev / Re: Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 15, 2017, 03:33:28 PM »

Let's take a step back and look at our options. The Audio Library enables the Teensy to stream sound data from two possible sources - an SD card or flash memory. It can then perform various tasks with the sound (mixing, adjusting, etc) and output to one of two outputs - mono analog using its single onboard DAC, or digital I2S data out.

If we use the onboard DAC, all we need to add to the Teensy (on the output side) is an amplifier IC. This is easy to do and there are lots to choose from. PJRC sells what they call a Prop Shield (not for propellers, for props) that uses a Texas Instrument LM48310; I have been using this for experimentation. Adafruit has an inexpensive breakout using a Diodes Inc PAM8302A. I'm sure there are a million other options as well. Both these listed operate at up 2.5 watts on a 4-ohm speaker which is probably more than enough for most 1/16 scale models and is equivalent to the Benedini TBS Mini.

In other words, in terms of hardware using the Teensy's DAC out is about as simple as it gets.

We could also use I2S out into a codec chip like the afore-mentioned SGTL5000 and then into an amp. This adds another IC but gives us some audio processing abilities we may not need.

I also recently discovered this fascinating combination I2S-DAC/Class-D amp chip that Adafruit sells a breakout for: MAX98357A. Feed it I2S digital audio and it will convert to analog and give you a hefty 3.2 watt amplified mono output you can connect directly to a speaker. I have ordered one to experiment with but don't have it yet.

All these options involve relatively inexpensive chips we can easily incorporate into our own board design. The final result I am shooting for is a small carrier board with a socket to plug in a Teensy 3.2. The carrier board will "carry" all the extra audio components we need such as the amplifier, plus the SD card slot, standard headers to attach HengLong/Taigen speakers and volume control knobs, and serial and power connections for hookup to the TCB.

So the question at this point is what hardware route to take. But we have some more things to consider first.

1154

Open Source Sound Dev / Open Source Sound using Teensy 3.2 and PJRC Audio Library

« on: January 15, 2017, 03:09:42 PM »

This thread will follow my attempts to create an open source sound card based on a Teensy 3.2 microcontroller featuring a 32 bit ARM processor (72 MHz Cortex-M4). It costs about $20 so represents a lot of power for very little money, and it's also very small.

All Teensy devices (there are several versions) are Arduino compatible and can be programmed using the Arduino IDE if you install the free Teensyduino add-on. Development can proceed rapidly because all the standard Arduino libraries can be used, and there are lots of Teensy-specific libraries available as well.

The greatest thing about this board is that it runs the Teensy Audio Library. This is an entire toolkit for building audio projects using a Teensy processor. They have a workshop you can go through that will probably blow your mind. I attended one of these in person last year for the express purpose of learning how we could leverage these resources for an Open Panzer sound card.

The workshop examples use a Teensy 3.2 mated to the PJRC Audio Adapter board. This board outputs CD quality stereo sound (16 bits, 44.1 kHz) and basically just consists of an SD card slot and an SGTL5000 codec chip. This chip takes I2S audio data from the Teensy (not to be confused with I2C) and with the onboard DAC converts it to analog audio. It has a built in headphone amp so you can listen on headphones without any extra hardware. But if you want to drive a speaker you have to add an amplifier circuit to the line-outputs. The SGTL5000 also has a lot of audio processing and signal conditioning features that can be manipulated through convenient functions in the Audio Library.

The Audio Adapter board is a bit overkill for our purposes. We don't need headphone outputs, we don't need stereo sound, and we probably don't need the majority of the signal processing capabilities. We do need however to drive a speaker and that requires yet another chip. However it would not be hard to create our own board with the SGTL5000, SD card, and a small Class D IC.

We do however have other options...

1155

TCB Dev / Re: Getting Started

« on: January 15, 2017, 12:15:59 PM »

Well it sounds like you have a very diverse background and I'm sure we will benefit from any contributions you may decide to make. The beauty of open source is that we can potentially involve a wide variety of skills and by definition, everybody working on the project is interested in and personally motivated.

As for projects on the shelf - believe me I have plenty of those too! But many of them are still there because I have focused on this one.

On the topic of code, there is a brief synopsis of all the custom classes used in the TCB firmware here: TCB Libraries. At whatever point people start wanting to change things, it is a good place to go to figure out where to look for certain functionalities.

Whew!  I had forgotten how long it took to install the Qt IDE!  .

Qt is a bear to get going as I recall, but simple to use once it is setup. This was my first exposure to it and I didn't take advantage of all it could do I'm sure. I hadn't figured anyone would bother to mess with it but seeing you charge ahead I hope we get more like you in time! There is much that could still be done on the Qt side.