Project Logs

Collapse logs

• Consumin'

  Ole Andreas Utstumo • 10/25/2019 at 13:47 • 0 comments

  Did a crude test on current consumption during runtime. During runtime, the MAX ECG circuit is the only thing running constantly, waking the MCU up from Stop mode every 32 samples so it can receive these via SPI and store them in the RAM buffer.

  180 ish uA on average. On a 240 mAh coin cell battery that should provide well over a week of runtime. All components are selected to operate below the "knee" of the battery discharge profile.
  

• Loggin'

  Ole Andreas Utstumo • 09/07/2019 at 20:14 • 0 comments

  Fatfs is working with the new flash chip, the USB MSC services are running, the ECG front end is now also running smoothly via SPI and we're logging data to files.
  

  Binary data straight from the front end obviously won't look good in a text editor...
  

  And if you're working with STM32 and haven't tried out SEGGER's excellent software packages, I strongly urge you to. They provide by far the most handy tools I've used yet for embedded debugging. The real time variable graphing tool is damn cool:
  
  

  
  

• Blinkin'.

  Ole Andreas Utstumo • 09/01/2019 at 17:51 • 0 comments

  All good so far.

• Mounted.

  Ole Andreas Utstumo • 09/01/2019 at 17:48 • 0 comments

  Three cards were mounted a while back. Hand mounting SMD components on a PCB backside is as usual a pain in the arse... I will hopefully never fall for that one again.
  

• Design files uploaded

  Ole Andreas Utstumo • 06/29/2019 at 17:35 • 2 comments

  ... And can now be found on the main project page. I hope I didn't leave anything important out of the project folder :-)
  

• Finishing up design & ordering

  Ole Andreas Utstumo • 06/29/2019 at 15:24 • 2 comments

  I think I'm done routing for now. It all fits nicely in a small package.
  I'll also upload the files and gerbers after I've done some tidying up.
  

• Divided by rings

  Ole Andreas Utstumo • 06/28/2019 at 21:48 • 0 comments

  Isolating and looking at my power planes in KiCAD, they seem a bit more divided than I wished they were..

  The clearance in the design rules is set to 0.2 mm, and the copper fill strangely gives way to via annular rings in other layers... Looking at the 3D Viewer it's more obvious what's going on:

  The via pad stack has annular rings in layers where they are unused -- and the copper fill respects the clearance just as being told. Poking around on the internet revealed that other people had the same issue, however, only workarounds seem to be available at the moment... I'm not gonna dig too deep into KiCAD, so I will let this one rest for now.
  
  

• Recommendations are just that pt. 2

  Ole Andreas Utstumo • 06/20/2019 at 11:11 • 0 comments

  As Jan pointed out in the previous log, the solder on the battery contact pad will oxidize. If the resistance in the contact builds up too much, we can solve it by placing some metal more resistant to corrosion and oxidation, like gold on the pad.
  

  A quick search reveals that there are SMD components which can help us out.

  https://www.mouser.se/ProductDetail/Harwin/S70-332002045R?qs=sGAEpiMZZMu2RFV024JNkxXHxBnx8LODQgUeuJAN3z3EkEymqw5JaA%3D%3D

  I'll implement Jan's idea of having a triangle of contact points.
  
  Initially I'll just use the pads with solder, and have these as a backup :-)
  

• Recommendations are just that.

  Ole Andreas Utstumo • 06/16/2019 at 21:12 • 2 comments

  Okay, my initial plan was using a four layer PCB with power planes as the inner layers, and signals traversing the outermost layers, to make for painless routing. That is until I checked the price of a prototype series with blind and buried vias at PCBWay.
  Obviously there are a bit more steps to the production of buried via PCBs than your regular 1.6 mm double sided green wafers of crispbread, and for a hobby project it's way more than what I want to commit. So I'll still run with a four layer PCB to keep my power planes intact, and let the signal vias run through the entire PCB. Then we're at 70 USD for 10 30x30 mm boards.
  
  So here comes the next problem: The CR2032 holder I picked requires a damn large pad on the bottom side for contact with the negative side of the battery.
  Which makes through vias problematic in 50% of the boards area when placed on the back side. I can pull GND down to the battery terminal, but anything else will short to the battery..
  I quite like the simplicity of these kinds of holders, though...
  Maybe there is a trick we can pull? The datasheet for the battery holder recommends a footprint, but there's no one saying we can do our own interpretation. As long as we make robust mechanical and electrical contact we should be good. So
  Becomes
  Instead of resting the entire negative face of the battery on a gold treated copper pad we can make two "rails" that are almost right underneath the springs on top push the battery down. The pads will be surrounded by solder stop which might have more height than the pad:
  That would be bad news for our electrical contact, so we could try to gain control over this uncertain situation by adding solder paste to the pad.
  
  That should do the trick, and now we have freed the necessary space to route the rest!
  
  As some one pointed out in the comments below, solder will oxidize. Hopefully it will be a minor problem...
  To be continued...
  

• Recovering

  Ole Andreas Utstumo • 06/01/2019 at 16:40 • 0 comments

  Among the things that could have caused the mass storage device to crash is timing issues. As the datasheet suggests, a minimum deselect time between each word in the write cycle must be T_BP = 10 µs.

  The HAL framework has no delay function for microseconds, so unless you want to implement this yourself, you could employ a dirty trick like this:
  

          for(uint16_t k=1; k < 55; k++){
              asm("nop");
          }

  A "nop" is an instruction that does nothing, but occupies a certain number of clock cycles and therefore a tiny amount of time. However, if you start changing the core frequency of the MCU, then interesting things happen, which it truly did in my case. Resetting the clocks to default, checking the write operation in the scope and adjusting k in the delay cycle above we're back on track. However, increasing the clock of the SPI has marginal impact:

  Those blue streaks are two bytes written to the flash plus a control byte. The parts where nothing is happening is sadly overhead in the HAL libraries and can be overcome by writing your own SPI functions, or minimized by increasing the clock of the core. For my use it's good enough.
  

View all 52 project logs