Rev_G Wishlist

[chipaudette]

We currently have no specific plans for making the next revision of Tympan. But, if we were to make another revision someday, what hardware changes would we like to have?

@biomurph, @eyuan-creare, @cab-creare-com, @mpu-creare, etc...if you have thoughts on useful hardware mods for the Tympan, please add a post here to this issue. Once I understand the request, I will then collect them into the list below.

Here are some changes for Rev_G where someone has expressed interest...

ELECTRONICS:

• Incorporate Teensy 4.1 & Tympan into the same PCB Like Rev D: Would make system smaller and would allow SD card to be put in better location.
• Push/Pull SD Card Slot: The current non-springing slot is a pain for users.
• Add breakout pads/pins for the JTAG interface. This will allow us to use a debugger while developing firmware.
• Bluetooth Audio and/or WiFi: This would require a new Bluetooth module, which would require revising the Tympan's bluetooth libraries.
• Newer AIC: Look for better audio performance or more audio channels than the TI AIC3206? Would require replumbing the Tympan's firmware for abstracting Tympan.h away from just the 3206.
• Include 2nd AIC By Default: Many applications require 4 channels, so why not just add the 2nd AIC on the main board?
• Make More Expansion Pins Available: Add a higher-density connector to expose more pins? Or, just add more pads on the PCB so that we can solder to the additional GPIO.
• USB C: Allows us to leave behind USB Micro
• Fast Charging: Charge the battery faster
• Power Management IC: enables shipping mode that only activates once a charger is plugged in
• Pads for optionally adding battery clips: Such as for using a single 18650 lithium cell
• Better Power Management During Programming: Remove the need to have a battery attached just to re-program the device.
• RTC Coin Cell Battery: Improve the RTC battery life, if possible. Also, use a larger coin cell for the RTC battery. Maybe switch to rechargeable coin cell? Maybe add protection to prevent overcharging of coin cell?
• Overvoltage Protection on Inputs: Add clamping diodes to prevent damage to the AIC if high voltages are applied at the input jack (and, mistakenly, at the output jack). Consider adding this protection to the AIC and earpiece shields, too.
• Push Buttons: 2-3 push buttons would be useful
• Brown Out Protection: USB Serial may not initialize if battery is low (how low?)

FIRMWARE:

• Support for Fuel Gauge IC: It's on the PCB in Rev F but we have no driver for it. Let's fix that!
• Better Default Firmware: Ship with demo firmware that cycles through (n) applications (Basic Gain, Pitch Shifting, 8-band equalizer, level meter ....)
• Speech Recognition: Perhaps feasible if we include WiFi, which would enable cloud-based APIs.
• More Pre-Compiled HEX: Upload hex files of each example sketch so that users can quickly try them out. Right now, takes several minutes to upload a new sketch.

HARDWARE:

• Snap together case instead of screws: Make it easier to assemble. Make it easier to open/close when hacking.
• Large flat section on case: For easy labeling with large font lettering

This list is not a list of action items. It is a list of potential changes that we will consider if we ever decide to make a Rev G.

[b-graybill]

Thanks, Chip!

[biomurph]

Thanks Chip!

• Incorporate Teensy 4.1 & Tympan into the same PCB, like Rev D
• Bluetooth Audio? Is this something that users have used?
• Is the current CODEC choice still our best option? Though likely that would be a big library lift

[cab-creare-com]

Yes to Bluetooth Audio

• Also requested by potential users: WiFi. (Particularly to support web-based speech recognition APIs.)

[eyuan-creare]

• Push-Push SD card slot
• High Density breakout connector for prototyping that exposes more uC pins
• (2) AICs (Seems that we often need 4-channel recording
• USB-C with Fast Charging
• I2C QUIIC connector
• Board defined feature that sets the Tympan Rev in the firmware, before loading everything else. For example, a few GPIOs or PRAM memory.

Nice to Have

• Power Management IC that has a shipping mode that activates when charger is plugged in
• 8-channel I2S see Chip's comment on issue].
• Pads for optionally adding battery clips for a single 18650 lithum cell
• Pads to expose more GPIO pins
• Develop driver for fuel gauge.
• Snap together case instead of screws
• Ship with demo firmware that cycles through (n) applications (Basic Gain, Pitch Shifting, 8-band equalizer, level meter ....)

Perhaps going to a PCB with more layers so we can pack everything into a smaller package.

[cab-creare-com]

• Power management fix to allow programming when powered via USB without battery (or when battery is discharged).

[chipaudette]

@eyuan-creare , Rev F already as the qwiic connector! (Spelling corrected. So hard to remember. Thanks Chris!)

[biomurph]

@eyuan-creare The quiic does not have a port in the current case design. Might be a good idea to post a design mod with a quiic port for folks to print if they want to?

[eyuan-creare]

@eyuan-creare The quiic does not have a port in the current case design. Might be a good idea to post a design mod with a quiic port for folks to print if they want to?

Good idea. Are the pads for a right-angle QUIIC at the edge of the board?

[cab-creare-com]

Before we get too far with this, the correct name is Qwiic: "https://www.sparkfun.com/qwiic".

[b-graybill]

Thanks for the qwiic reply, Chris!

[eyuan-creare]

I knew you or Chip would correct me, so this was the most efficient path to the correct spelling ;)

[b-graybill]

Large flat section on case for easy labeling with large font lettering

[biomurph]

Here is the Qwiic connector position

[cab-creare-com]

Improve RTC coin cell battery life. (Re: #12 (comment))

[eyuan-creare]

Improve RTC coin cell battery life. (Re: #12 (comment))

Maybe a rechargeable coin cell? Shorter run time, but rechargeable. Hopefully find one with UN38.3 certs.

[eyuan-creare]

Protective Circuit for Coin Cell [minor]

• Add resistor inline to prevent overcharging the coin cell when the Schottsky diode fails. Referenced in many designs and datasheets for suggested battery backup circuits.

From Teensy 4.1, showing bus voltage and coin cell going through separate protective diodes:

Tympan connects directly to VBatt

Note that Teensy uses diode BAT54C which should leak <2uA of current when the supply voltage (3.3V) is higher than the coin cell. Seems fine though did not see a spec on allowed coin cell reverse charge current.

[chipaudette]

We may have had someone damage their Tympan by applying 5V to the audio input jack (the pink jack). Perhaps we should add over-voltage on this connection?

[eyuan-creare]

• Brown out protection. USB Serial may not initialize if battery is low (how low?)
• Ability to run the Tympan with only a USB connection, no battery
• Upload hex files of each example sketch so that users can quickly try them out. Right now, takes several minutes to upload a new sketch.

[eyuan-creare]

(2 to 3) Physical push buttons on the board

[chipaudette]

• Upload hex files of each example sketch so that users can quickly try them out. Right now, takes several minutes to upload a new sketch.

@eyuan-creare , I know that you're a fan of HEX files. More of a fan than me, for sure. In my experience, the process is never as easy as one hopes, at least from a new-user perspective.

When I've offered it to people, these are people who have just figured out how to compile our Examples using the Arduino IDE. That was hard for them, but now they feel a tiny bit of success. When I offer an "easier" solution that involves completely changing the process, it's given everyone pause. It seems like it's too abstract for inexperienced users who only know the comforting blue/green of the Arduino IDE.

Perhaps if the HEX files used a comfortable web-based uploader or something, that would be different. But, no, you have to use the Teensy uploader (Teensy.exe). Ah, the Teensy Uploader...what a weird too-small piece of software. Also, it's impossible to find on one's computer! Here it is on mine:

C:\Users\Chip\AppData\Local\Arduino15\packages\teensy\tools\teensy-tools\1.59.0

Be aware that, "AppData" defaults to being hidden/protected on the default Windows installation. Yikes! Even if get over that hump, you've got to drill down 8 more directories, 3 of which are dependent upon your particular installation ("Local", "Arduino15", and "1.59.0"). That's a lot of opportunity for failure!

As a completely separate criticism of HEX, I find HEX files difficult to manage. How does one keep them up-to-date with underlying source code? Currently, it has to be done manually...manually ask it to produce the HEX, manually copy it to the directory with its associated *.ino, then manually delete the build directory. Ugh. that's a recipe for being out-of-sync, for sure.

Maybe we could set up an automated process, but maintaining automated processes has been difficult in the past. KXM and I tried a travis-based production release system years ago...the system didn't last but a few months before some dependency changed and broke the whole system. I didn't have the skills to fix it and those with the skills didn't really have time. Bummer!

This is me being overly-negative about HEX. Compiling the examples oneself has its own problems. I know that you've had more positive experiences with HEX. Tell me more!

[eyuan-creare]

@eyuan-creare , I know that you're a fan of HEX files. More of a fan than me, for sure. In my experience, the process is never as easy as one hopes, at least from a new-user perspective.

Good point. I think there are two things that I am considering:

• Hex files document tested code, independent of differences in the compiler or libraries. When doing research, it's good to know that when a hex file is uploaded, it is the exact same version as when it was last used.
• For users who may be using the Tympan as an open source research tool, rather than a development platform, there may be an easy way to streamline the hex upload process, using a bat file or tablet app to kick off the CML version of the Teensy. Perhaps to some users Arduino's IDE may be daunting.

In terms of uploading hex files, we could start by including a hex whenever we release and test a new software feature (not necessarily keep all the hexes up to date with the latest rev). Just a snapshot in time when things had worked. Then when new hardware is released, upload them when we happen to test and verify a script is stable, for those sketches we commonly use. Perhaps not the time yet to put this into play.

[chipaudette]

@eyuan-creare , you've painted a good picture, especially in drawing a difference between researchers vs developers. Continuing with this idea, I might suggest keeping the collection of hexs in their own repo. This repo being aimed at researchers / regular users rather than developers. The docs for the new repo (readme, for example) could be aimed at this kind of user..."how to use these files to easily discover the Tympan". I like that. A clear purpose, with words that help people realize that this is what they want.

Additionally, using a separate repo for the hexs addresses my concern of the hexs being hard to maintain, it addressed the challenge of keeping them matching the latest Tympan_Library code base. If the hexs are in a separate repo, it isn't necessarily expected that the hexs will always perfectly aligned with the developer repo (ie, Tympan_Library). In other words, the hex repo could have its own releases, with notes as to what standard the hexs were made to. Having a hex-only repo gives up more options for keeping hexs for the diff versions of Tympan, too, if we desired.

What do you think about the hexs being in their own "For Researchers" repo? From your viewpoint, does this achieve your vision better or worse?

[biomurph]

@chipaudette
I like the idea of a separate repo. That will make it easier to maintain and build.
I also get you when you say the Teensy loader can be a tedious tool to work with.
Teensy Loader is available as a stand alone app, it seems.
https://www.pjrc.com/teensy/loader.html
has anyone tried it with Teensy 4.1? If it works, we could incorporate it into a tutorial or guide to make the process more straightforward?

[cab-creare-com]

BAyotte has been loading Hex files directly on a Tympan Rev F, following the instructions in "https://github.com/Tympan/Docs/wiki/Program-the-Tympan-from-a-Single-Hex-File#uploading-a-hex-file-to-the-tympan-1". That involves digging into the Arduino app data directory that @chipaudette mentioned.

I'd be in favor of adding instructions for how to use the standalone Teensy loader.

[chipaudette]

Oh man! One can download the Teensy Loader directly from the web?!? That totally addresses my concern! Thanks @biomurph!

[biomurph]

There is an active tutorial on pjrc that uses the stand alone be loader to flash micro python... It would need some basic testing.

[cab-creare-com]

The battery charger/Tympan power circuit needs some attention. Charging the battery should not take priority over powering the Tympan main functionality.

From @chipaudette:

In looking at the battery charger IC that’s built into the Tympan, I found some interesting limitations that might related to your recent experience with an overly-discharged battery.

• Normal Operation: The battery charger IC is designed to limit the current being delivered to the battery. The limit is 500 mA. This also means that the IC limits the current (from USB) being delivered to the Tympan itself. The Tympan will only be allowed to pull 500 mA from USB. We have always assumed that it is this limit that prevents our system from being reprogrammed if no battery is attached; we have assume that 500 mA must be not quite enough to push through all phases of reprogramming.

• Overly-Discharged Battery: Reading the datasheet for our charging IC, I see that it has a “pre-conditioning” charging phase, where it limits the current delivered to the battery to prevent damage to an overly-discharged battery. For our charger, if the battery voltage is less than 2.77V, the current from USB is limited to only 50 mA! Again, the limiting current to the battery is (in our system) the same as limiting current to the Tympan itself. So, if the battery is drained below 2.77V, the Tympan will be limited to 50 mA. The system will not be able to boot on so little current.

[chipaudette]

From @cab-creare-com

The battery charger/Tympan power circuit needs some attention. Charging the battery should not take priority over powering the Tympan main functionality.

Agreed.

As @biomurph has already made his own version of the Adafruit nRF52840 Express, we could use its charging / power supply as a model. https://cdn-learn.adafruit.com/assets/assets/000/068/545/original/circuitpython_nRF52840_Schematic_REV-D.png?1546364754

[eyuan-creare]

For the meantime, how about a software version of UVLO? When Tympan's analog battery voltage measurement is low, shut itself off.

If reconfiguring power management, might as well consider USB-C fast charging.

[biomurph]

@chipaudette Yes, we can use that topology to ensure the VBUS will power the system even when charging the battery.

[cab-creare-com]

It's worth reviewing recommended circuits for USB & rechargeable battery powered devices. The Adafruit nRF52840 Express design is not ideal:

• When the battery is being charged and the MCU is powered on, the device potentially exceeds the allowable power draw from a USB 2.0 port (500 mA).
• When the MCU is powered off, the battery may not be charging as fast as possible. (Depends on R4 value and the battery specs.)