Project Logs

Collapse

• Rev 0.2

  OzQube • 01/12/2024 at 02:38 • 0 comments

  Next lot of PCBs are in. These ones fixed the wiring of the level shifter IC so that I can actually use the header pins! I also made the SWIO test point a little larger.

  Unfortunately, I hastily sent the order before making any other changes. 

  After looking at the board again, I subsequently made additional changes to the layout to improve the board. I moved the I2C pullup resistors close to the QWIIC connector, which gives me a bit more room for the level shifter and other resistors near the header. I also added a little more space between the components in the RF path, to reduce the chance of solder bridging. 

  I'm sure there will be further changes before another respin, so I'll try and keep track of what I've changed. 

  ---

  Evolved project ideas.

  Considering the CH32V003's main feature is it's affordability, it doesn't quite make sense to match it to a $12AUD RF Transceiver ( in single unit qty). True, it goes down to $9AUD in units of 100, but that is still way more than the microcontroller cost. There are other Silabs transceiver ICs with lower output power that are slightly cheaper, but we're only talking a few dollars. 

  One option may be to link the CH32v003 with the CMT2300A Transceiver from CMOSTEK (Wuxi Zetai Microelectronics Co., Ltd.) CMOSTEK appears to be a fabless semiconductor company. The chip is available from LCSC for under $2AUD, but it appears to come from HOPE RF, who also manufacture Transceiver ICs that are almost identical to the Silabs Si4463 ( i.e. the RF26W on the RFM26W module). The datasheet for the HopeRF module is almost identical to the Silabs one. The CMT2300AW chip from HopeRF seems to be identical to the CMT2300A from HopeRF.

  The specifications for the CMT2300A seem similar enough to the Si4463., but unfortunately the registers are completely different, so there's no overlap in code. 

  Another option using Silabs chips is to use the Si4460, which only has 13dBm output power. Rather than using discrete components in the matching circuit, Johansen Technology make a single component that contains all the required attributes for the Si4460 - the 0433BM41A0019001E . This would make the PCB much more compact, but have lower performance. 

  The software side is not my strongest suit, so that remains the biggest hurdle. Anyone out there that's familiar with this MCU is welcome to assist!!

• Radio driver evaluation

  OzQube • 12/01/2023 at 11:47 • 0 comments

  The SI4463 is a little complicated to get working. There ARE some libraries out there in the Arduino world to connect to these chips, such as the Radiohead packet radio library, or the one from Zak Kemble.

  Initially, I tried to use both of these, but each failed to compile for different reasons. 

  The Si446x library from Zak Kemble fails to compile due to incompatibilities with how the Arduino port for the CH32V003 handles interrupts. 

  The Radiohead library fails to compile as the "utils/atomic.h" file is missing.  This file seems to be part of the AVR GCC code. 

  So this means I may have to write a driver from scratch :-(

  The Silicon Labs WDS software generates some C code suitable for it's own RF devkits, but this seems quite bloated and hardware-specific - although it does separate out it all into a standalone radio hal.

  Another source of pre-made code could be from other STM8-based radio modules. A Chinese company called Chengdu Ebyte Electronic Technology Co, or just Ebyte, make a SI4463 module with the part number E10-433MD-SMA. It's designed to connect to a small STM8-based dev board- E06-TB10. I managed to find some demo software for this board, which also included a basic driver. 

  This might just be a good template to use for this project, considering the HC-12 uses an STM8.

  Then there's the minimal driver option. The Pecan Femto 2 HAB balloon used this architecture to initialise the SI4464 and get it to beacon information. 

  As I'm going to try an use the HAL for the CH32V, the last option seems to be the fastest way to verify the radio IC is indeed working on these boards.

• Board assembly - The good, the bad and the ugly.

  OzQube • 11/27/2023 at 12:20 • 0 comments

  For some reason, I thought that I had all the required passives in my horde of components - alas no. I ordered it all and finally got round to assembling the boards.

  As I didn't order a stencil, I had to manually apply solder paste to the pads. I used whatever I had on hand. (Note to self - get new paste!). The 0402 components were ok, but the RF IC and the level converter IC are really tiny, so I had to use the "blob on and wick off" technique. I hand placed the components, then reflowed on a hot plate. A couple of the 0402s wanted to tombstone.

  After getting everything looking OK, I went to clean the pcb in 100% isopropyl......but I realised that the paste I had used had No-Clean flux - leaving a white residue everywhere.......

  After a go with some proper PCB cleaner, they started looking reasonable.

  Time to program something. 

  One issue I realised very quickly was that the 0.8mm test pad I was intending to use for programming is way too small. After I soldered a wire to it, it just ripped up off the board! I taped the wire to the back of the PCB for support and soldered it direct to the SWIO Pin (Pin 18).

  I connected the WCH-LinkE programmer to VCC, GND, SWIO and RX. After creating a new blank project in MounRiver Studio IDE, it still has some basic USART loopback code in it. This would be a good test to see if everything is working. Next problem - the project wouldn't download as the firmware for the WCH-LinkE was not up to date. I tried clicking "Yes" to upgrade the firmware, but it failed. Then it didn't recognise the debugger :-( .

  Some googling on the steps to manually update the firmware revealed that I'd need to press the "IAP" button, then try to upload again. The button is inside the strongly stuck together clear case of the programmer. No access to the buttons! Rather than break the case, I drilled a 2mm hole in the plastic, then used a paperclip to press the button. This was supposed to turn on a blue LED, but that wasn't working for me.  The update wouldn't get triggered as the IDE kept saying that no programmer was connected. In the end, I ran the WCH-LinkUtility, and ran the "Target > Connect WCH-Link" option, which DID prompt to upload new firmware. Success! The WCH-LinkE could detect the connected CH32V003.

  I downloaded the program to the device. Programming successful!

  But the USART didn't seem to be responding........

  I checked all my soldering and that seemed to be ok. Next step is to check the schematic......

  Looks like didn't read the datasheet of the USART level shifter IC - TXU0202DTTR . I had wired the incoming TX pin straight to the RX pin. I had picked this chip as it offered the full 1.1v - 5.5v on each side of the serial bus. This would allow connection to most external microcontrollers, plus allow the chip to work at a range of voltages if required. In hindsight, the small SON package I chose is a pain to solder... I should have stuck with the VSSOP with external pins. 

  To get these prototypes to work, I just needed to remove the level shifter and solder a really fine wire across the pads to bridge the incoming pins to the MCU pins. The tiny pads made it hard to get enough solder so that I could attach the wire, but eventually I managed to get it done. I verified continuity with my multimeter, then hooked up the programmer again. Connecting the serial console, I power cycled the board and the USART showed an output! (the clock speed and the chip unique ID) .

  So now I need to learn how to use the HAL that's included in the MounRiver IDE and get the chip talking to the radio IC. Stay tuned. 

  In summary, here are the issues with rev 0.1. I've added some other ones that I haven't described in this log, but are things that could be improved upon.

  1. Programming pad too small
  2. Level Shifter wired incorrectly
  3. Spacing between some components too small

  I'll tweak...

  Read more »

• 1st boards are in!

  OzQube • 06/29/2023 at 11:09 • 3 comments

  After a 2.5 week postal journey, the first rev boards have arrived from OshPark

  They’re still pretty small. Only slightly bigger than the original. I’ll sand the edges to remove the routing stubs and the swarf on the edge of the castellated holes. Then some manual paste application (I didn’t order a stencil for this revision. Maybe once the design is final and I panellize it, I’ll get a proper stencil done. ) 

  All the parts arrived before the pcbs, so next project log will be once they’re assembled. 

• Prototype board

  OzQube • 05/21/2023 at 04:16 • 0 comments

  I've started designing a prototype board.

  The original HC-12 is 14.4mm x 27.4mm. It appears to be a 0.8mm thick PCB. 

  To fit in the QWIIC connector, I've increased the size slightly to 16x29mm.

  There's work to do to standardise the 0402 footprints. The various Eagle libraries I used have different pad sizes, depending on whether it's an inductor or capacitor. 

  I've designed around using the OSH Park 4 layer PCB. A quick search online lists the recommended trace width and spacing for 50 Ohms. Once I refine it for a 0.8mm PCB, these settings will change. 

  I also need to make a custom footprint for the castellated edges. My spacing isn't right and it breaches the design rules if I move the pin header row any closer to the edge of the board. 

  The actual values of the components on the REF side aren't known exactly. I've used the schematic from the Silabs App Note AN648 . It lists calculated values for Class-E Switched TX/RX Board Configuration, but only for 390Mhz and 460Mhz. As 433Mhz is approximately halfway between these, I'll guesstimate the values that should be selected, based on the nearest standard value that is the midpoint of the values listed in the App Note. 

  Another thought is to increase the size of the input capacitor for the LDO. Most applications have recommended putting a larger capacitor on the Vin line, so if I can shuffle things around to fit in something larger, I will. 

  I'm also tempted to increase the board size slightly to have an actual pin header for programming. Otherwise, I'll just have to solder wires to the test pads. 

• Analyzing the HC-12 SPI Bus communications

  OzQube • 05/14/2023 at 11:31 • 0 comments

  The default SPI commands for the HC-12 are listed on the STM8 eFourth WIKI HERE.

  Using both the API and the WDS software, I worked out what the commands represented, then applied the relevant settings to the WDS software so that it can output a radio configuration header file that can be used to program the radio.

  Some things I noticed:

  • The SPI commands don't quite match the sequence that would be used if the HC-12 had been configured using the WDS configuration file ( i.e. the WDS file groups certain commands into a sequence. The HC-12 firmware groups some, but then sends some commands individually, and not all the generated commands are applied - possibly because some configuration isn't actually required as the chip is just using the power on defaults for those settings)

  • The radio is initially configured for 250kbps, then applies the specifics for the FU3 mode of 15kbps. (Seems a waste of code. If FU3 is default, then that should be the default setup)
  • The current WDS ( version 3.2.11) isn't able to generate the exact same config. It appears that some settings have been either developed manually, or previous version of the software generated different code.
  • The "Filter coefficients" are hard to interpret!!

  I've decoded most of the commands. Still TODO is to work out the frequency and filter settings.

• Initial thoughts

  OzQube • 05/11/2023 at 23:01 • 0 comments

  The original HC-12 appears to come from the HC01 factory. Clones have been made of this module, some of which had bad quality components, which left the range much less than advertised!! (Search Hackaday for HC-12).

  The module is simple and easy to use, but offered no expansion options. It wasn't designed to be reprogrammed easily. The STM8 micro has 1K of RAM and 8K of flash.

  There has been a little bit of interest in reprogramming the original HC-12 module. Another Hackaday.io project log mentions it https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets/log/58808-starting-to-work-on-the-hc12 .
  

  Recently, the WCH CH32V003  was released, with an almost identical  pinout to the STM8S used in the HC-12. It has double the RAM and flash, and has a 32-bit RISC-V core. I put out a post on EEVBLOG Forums suggesting someone should perform a swap on the HC-12 module, but noone took the bait! But rather than just perform a MCU swap, I wanted to make an improved version. So I placed my order for the chips and have now started the design.

  The design goals are:

  1. Keep module small and simple to interface
  2. Make module compatible with 5V and 3.3V without external components
  3. Add expansion option
  4. Initially, make the new device compatible with the default settings of the original HC-12, then add other features later.

  The original HC-12 has some limitations on the power side. The recommended power supply is 3.2-5.5V, however if feeding it >4.5v, then the manual suggests to add a diode on the input to (presumably) dissipate some heat through the diode due to the diode's voltage drop, which in turn reduces the voltage at the input of the LDO so it doesn't get too hot.
  

  The UART interface is level shifted to the 3.3v/TTL level for the STM8, and has inline resistors for protection. 

  My initial thoughts are to change the LDO to a buck/boost arrangement, which will be more efficient if being powered from higher voltages. Plus allow a 3.3v supply to be passed through.

  On the UART side, maybe something like TI's TXU0202 which is a single chip solution for level shifting. 

  Even though my new module is based on the HC-12, by developing a new pcb, the CH32V003F4P6 pins can be assigned in a slightly different way, allowing I2C pins to be available. I plan to put a QWIIC/Stemma QT  (JST SH) connector on the board to allow peripherals to be connected directly.

  My next task is to figure out what the default settings are. The HC-12 manual says that the default mode is FU3, which has a UART speed of 9600bps (8,N,1) and an over-the-air data rate of 15,000 bps, Default frequency of 433.4 Mhz. The Si4463 radio IC has a complex API with alot of options to configure. Luckily, one of the developers of the eFourth adaptation for STM8 undertook the task of sniffing the SPI bus while the chip initialization was taking place. The list of commands is HERE .

  I'm currently working through the list and cross referencing the API to understand what settings have been applied. 

  Each line is a command sent to the radio IC. A quick summary is:

  0x02 is the POWER_UP command.

  0x13 configures the Radio IC GPIO pins

  0x11 sets the radio parameters. (There are lots of these!)

  A future post will have the breakdown. 

View all 7 project logs