Hi everybody,
I finally found some time to read the TR-9 schematic. I take the freedom to comment a little bit on my findings. It is by no means thought as general critique on the concept. Nor is it a formal review as I don’t think this is necessary in this stage of the project. So please accept my comments as positive feedback and food for thoughts.
-
Requirements specification
There is no top level requirements specification (at least I could not find anything). I understand that this kind of hassle is very often avoided (also in commercial projects) but I think it is very important. I might be a good idea to shortly sketch the design goals, most important interfaces (e.g. energy sources planned in the design), overall structure of the hardware.
This does not need to be a novel sized piece of art, a few lists and / or tables with requirements and maybe some diagrams are sufficient. This document will grow with the project. -
Power requirements / consumption
So far I understand this should be a handheld device with limited battery size. Overall power consumption is quite important therefore. Now the definition of “low power” is somehow relative. If You ask somebody who works in the motor driver business he considers everything below a few tens of watts low power. If You are designing a LoRa module with 5 years+ battery shelf life You start to count electrons. My experience with several projects of the second kind taught me that permanent consumers are the ones to concentrate on. I found several possible candidates in the schematic which may severely limit battery life. -
So lets turn to the schematic. I follow the pages and list (without specific order) my findings and / or questions:
3.1.
a: OS1 is a “low power” (guess You expected the “” 
) oscillator. As used here it runs continously so the around 4mA are consumed no matter if its precision is needed or not. The STM32 processors have a sophisticated clocking unit which, should the external oscillator fail will automatically switch to the internal oscillator (datasheet chapter 2.15). This could be used to save a considerable amount of power. The external oscillator can be disabled via pin 1. If its accuracy is not needed just turn it off. The internal oscillator will take over automatically if needed.
b. USB: The STM32 processor is ready for USB-C. Why not use it? Maybe something to postpone but USB-C is the future: high speed, higher power capability, batteries could be charged through it, etc.
3.2: well. Clearly under construction. May I make a suggestion?
- 2 18650 LiIon cells in series. Charger through USB-C, two DCDC converters for 7.5V (PA, Preamp) and 3.6V to 4V as preregulator for 3.3V LDOs for the rest. 7.5V DCDC converter can be disabled if not used to conserve power.
3.3: 5V really needed? I assume the TFT display chosen may need it, but this could be generated locally with a tiny step up converter.
3.4 Not many questions. I am not the expert on RF power amplifiers. What might be something for a future design is using a class-E design for its higher efficiency. But as we are talking about UHF here this may be just marginally more efficient.
I have a question though about the bias circuit. Does this opamp need 5V or would 3.3V be sufficient? If not could it run from +BATT? (again to get rid of the the 5V supply).
3.5 Audio output. The LM386 is an ancient amplifier chip. Certainly ok of the purpose it was designed for but as an audiophile I shiver from the sound it produces. I think it was Rick Campbell KK7B who first urged designers to use high performance circuits in the audio path. Not because Your squeeking signal will then sound like an opera singer but because it does not add further “squiekiness”.
Apart from that the LM386 has quite a high quiescent current.
The STM32 used here has a digital audio interface (including I2S). It might be possible to use a class-D audio amplifier chip. Eg. the SSM2518 is a complete stereo amplifier with exceptionally high efficiency. Volume could either be set with a rotary encoder or reading a potentiometer value with one of the ADC channels.
Again maybe something for future iterations.
3.6: just a question: what is U11 intended for?
3.7: Looks like You want Wifi? Why not use an ESP32 in RMII mode? The STM32 does have such an interface and all the logic needed for Ethernet. Again: maybe even further in the future.
- HMI Board: Is X1 needed at all? (power consumption). Maybe this functionality could all be handled by an ESP32?
Just a few last notes on the overall structure. I like the fact that HMI is separated as much as possible from the rest of the system. This may allow to operate the radio “headless” through Ethernet in a later stage. I think of using the radio through a web interface (be it over a PC or smart phone) might be a nice use case.
Do You guys already have some experience on EMC problems of the design? What I am missing somehow are shieldings for sensitive parts (e.g. for RX and TX, particularly PA part).
I definitely expect some side effects from DCDC converters, no matter what topology is used. So it might be a good idea to shield the power supply section as well.
A last idea on the protocol: would it make sense to have some slow acting automatic TX power setting (using some nifty QOS data exchanged between the two stations involved)? This may help to keep radiated power as low as possible and additionally conserve power.
Puuh, that was quite a lot of babbling. I hope this was not too wooly and unconnected.
Questions always welcome
Best regards und 73 Robert HB9DNN
).