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.
1. 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.
2. 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.
3. So lets turn to the schematic. I follow the pages and list (without specific order) my findings and / or questions:
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.
4. 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
Just to begin, I really appreciate that You looked into our project, and shared what You think about TR-9.
Specification of TR-9 is in progress, and will be published before the end of this month.
I work on design a PCB for TR-9, and I'm about to finish it, tommorow, or day after.
Oscillator on/off using pin is a good idea, and I just added connection.
I will think what You wrote about, but there are some things, that I can't change in this version. I'll write what I changed next day!
You haven't noticed - there is a place(removed soldermask) for EM shielding - for PA, and RF chipset.
You cannot see attachments on this board.You cannot see attachments on this board.
We can even separate GND(avoid ground plane) for DCDC converter, which will be filtered using caps(GND-VCC) from two sides - input and output of converter. I think it can mitigate EMI.
I think it's a good idea to second HW rev of TR-9.
73! from Niko SO3ALG
Thanks for your feedback! I had some connection problems and my previous post got lost. This is a concise version of it.
1. Do that, publish it here. We can edit it later.
2. We didn't perform any optimizations there, as this version is considered a Proof of Concept. Of course it has to be done later and we will certainly focus on that, when the time comes.
3. 5V is used for the TFT and one op-amp in the RF section. The latter can be theoretically powered with 7.4V and the TFT can use a local (placed on the HMI board) DC-DC taking 7.4V input.
4. LM386 is more than enough for this application. DB9MAT suggested, that shutting off this amp is not worth it. I'd focus on the mic section instead.
5. U11 is for motion detection. Can be used for APRS and telemetry stuff. Good to have it.
6. Why would we want to use RMII? UART is enough for sending some JSON queries and stuff like that.
7. We could use async (USART) comm between hmi-mainboard and omit the XO, yeah.
8. No QOS in half-duplex.
thanks for Your answer. I will comment on a few details (which does not mean that I don't care about the rest ;) ).
QuoteSpecification of TR-9 is in progress, and will be published before the end of this month.
Oh, that's great. If You want me to have a look at it, let me know. I will be happy to help.
QuoteI will think what You wrote about, but there are some things, that I can't change in this version. I'll write what I changed next day!
I did not expect to have anything changed at all (now) I just wanted to share my ideas and questions. As SP5WPP wrote this should be a demonstrator and that's what I also understood it will be. You can only gain experience with real hardware so keep on :) .
QuoteYou haven't noticed - there is a place(removed soldermask) for EM shielding - for PA, and RF chipset.
I have to admit I only had a look at the schematic yet. As I did not find any information on shielding there I (wrongly) assumed there is none. (I use to define components for shields so it appears in the BOM and can be connected to GND. This is why I missed this here).
QuoteWe can even separate GND(avoid ground plane) for DCDC converter, which will be filtered using caps(GND-VCC) from two sides - input and output of converter. I think it can mitigate EMI.
I think it's a good idea to second HW rev of TR-9.
My experience is that it is nearly always a bad idea to separate ground planes. There are exceptions but usually the most important thing is to concentrate on minimizing path lengths and (shielding) confine RF as much as possible. But again: keep on, practical experiments will show potential weaknesses. You can't simulate and / or design everything.
vy 73 Robert HB9DNN
thanks for Your answer.
QuoteThanks for your feedback! I had some connection problems and my previous post got lost. This is a concise version of it.
1. Do that, publish it here. We can edit it later.
I already asked Niko to share what he has. I will be happy to help here.
Quote2. We didn't perform any optimizations there, as this version is considered a Proof of Concept. Of course it has to be done later and we will certainly focus on that, when the time comes.
That's perfect. A real functional model will show what is really needed.
One suggestion, though: add 0-Ohm resistors between power sources (LDOs) and loads. This simplifies measurements tremendously and allows to disconnect parts of the circuit should it make trouble.
If You don't like the idea of so many additional resistors which have to be assembled: short them with a cuttable trace.
Quote3. 5V is used for the TFT and one op-amp in the RF section. The latter can be theoretically powered with 7.4V and the TFT can use a local (placed on the HMI board) DC-DC taking 7.4V input.
Ok I understand.
Quote4. LM386 is more than enough for this application. DB9MAT suggested, that shutting off this amp is not worth it. I'd focus on the mic section instead.
Fair enough. The LM386 certainly works I just don't think it is up to the rest of this innovative project. But don't get me wrong: nothing wrong using it :-) .
Quote5. U11 is for motion detection. Can be used for APRS and telemetry stuff. Good to have it.
Ah, ok. Good idea.
Quote6. Why would we want to use RMII? UART is enough for sending some JSON queries and stuff like that.
I was just thinking loud. As I don't know all the details on usecases for Wifi I thought about what would be possible with it. As I already mentioned for a headless design it might be helpful to have some additional bandwidth.
Quote7. We could use async (USART) comm between hmi-mainboard and omit the XO, yeah.
I assumed it is a one way UART interface. Except for high baud rates I guess the internal oscillator is accurate enough. Once more: experiments will show.
Quote8. No QOS in half-duplex.
That's why I said *slow*. Both sides could exchange some QOS information occasionally. I will read the protocol specification next to better understand it. Maybe my idea is just to far away from what is intended here.
I only mentioned this point because the experience with analog relays often is somehow disapointing. There are always fellas who think more power (or as bad as the first) more FM deviation gives them some advantage.
Shure, QOS in cellular networks is a completely different can of worms and very sophisticated. But nevertheless it might be a nice idea to experiment with.
vy 73 Robert HB9DNN
Quote from: undefined7. We could use async (USART) comm between hmi-mainboard and omit the XO, yeah.
Quote from: undefinedI assumed it is a one way UART interface. Except for high baud rates I guess the internal oscillator is accurate enough. Once more: experiments will show.
I made a typo, I wanted to write "sync" :) But you are right.
my turn to add remarks.
First of all thanks for starting that project, it is very needed by the ham community.
Is this PCB in the process of being fabricated, or are there plans to update it before it is made?
About esp8266: This chips is very obsolete. Can a wroom-esp32 be used instead? If that is too big, then I guess that an esp32 daugter board with the esp8266 pinout is the only solution...
I also second the USB-C option instead of micro-B, the USB-C plug is far more robust. Wurth has a version that can be hand soldered.
I am definitely IN when a PCB is being ordered. I will build a beta device to help testing and software development.
About software, my idea is to avoid stm32cube and go with libopencm3. The best option would be the NuttX RTOS, which I have used a lot and I can help with porting. That would be very useful to have a RTOS instead of some bare metal adhoc code.
Final words, the codec2 code is very inefficient for embedded use as it uses floating point. It requires a huge mcu. I have started documenting the codec2 algorithms and writing a fixed point version. This is a lot of work and is currently on hold. This project could revive this. Any help would be appreciated, I can provide what I did, of course it's open source, and was started with the goal of such a project.
I have done a 433 MHz base station (hn70ap) with a si4463 and Ethernet with a stm32f429 and NuttX. This board has no real purpose yet, but m17 could be THE purpose :) I have started reverse-engineering the si4463 config generator so the dependency on silabs tools can be removed. Also, a project on hold. m17 could revive it.
Niko SO3ALG is about to publish the gerbers as I'm writing this post.
ESP8266 chips might be obsolete, but are very popular and easily obtainable. We might switch to something else later.
Why USB-C if ordinary USB is more than enough? We aim at data rate 115200bps, at most, there.
I'm going to order some 20+ PCBs just when the gerbers are ready.
Why avoid stm32cube? Older versions are good. I won't use any RTOS in my handheld.
STM32F777 has an FPU unit, so the last argument voids. Si4463 is no longer in use in M17.
just read Your messages in IRC and, honestly, was kind of embarrassed by the wording of some of them.
Not that I take this personal but ridiculing others in a discussion is definitely not helpful for such a project.
If You consider this project Your property; well, be my guest. I don't think, however, that my questions and ideas and F4GRX' remarks are just stupid babbling which are only worth to be crushed down.
Maybe You rethink about the reason why we two proposed using a USB-C connector. Hint: it has nothing to do with data rate.
I hope this is not the usual way folks are treated here.