Author: Carsten Presser

Checking KiCad symbols

In summer 2019 I have been invited to join the KiCad librarians team. As a librarian my job is to review additions and enhancements of the KiCad-library. Those include footprints and symbols in their respective repository.

All submissions should adhere to the KiCad Library Convention (KLC) which is a set of guidelines to follow when contributing to the library.

Unfortunately there is no on-boarding for new maintainers. And no ‘real’ process for checking contributions. It is up to the reviewer to learn all of that themselves. Thus, I decided to write down a small list of the items I usually check when looking at submission. This list is not comprehensive, so only take it as a starting point!

  1. Could the new symbol be an alias to an existing one
    • If its an alias, some of the checks can be skipped since the base part is already in the library. Only the dcm file which contains the keywords and description need detailed checking.
    • A quick check for the base part should be done anyway. This is a great opportunity to find bugs. If possible also fix cosmetic issues if it does not break compatibility.
  2. Are there symbols with similar function already in the library? If yes, does the new symbol conform to the style set by the existing ones?
    • Sometimes the existing style does not conform to KLC. Then some research should be done to figure out why that is the case. Some symbols are rather old and were made without proper checks
    • Perhaps the existing symbols needs rework as well. If its just a small amount of work and a non breaking change the contributor can be asked to take care of that as well.
  3. Is the new submission in the correct library section? There are some corner cases or even devices that by no means fit into an existing library. Then a new library can be started.
  4. Is the new symbol a generic or a fully specified symbol
    • Should there be additional aliases? For example fixed voltage regulators usually come in with different voltage options. It is good to have one alias for each output voltage.
  5. Check the Symbol name
  6. Pins
    • Verify names and pin-numbering against the datasheet
    • Are the pin electrical types helpful for the DRC? Most datasheets give information about pin types. Look for open-collector pins, special power pins, …
    • In most cases the GND pins can be stacked. Sometimes this also applies to power pins or even I/O.
    • If the package has an exposed pad or other features (shield, mechanical mounting), is that properly represented in the symbol
    • NC pins should be on the outline of the symbol body.
  7. Pin layout (which pins go on which side of the symbol)
    • Again, check for consistency with similar symbols
    • Perhaps ask the contributor to provide an example how the symbol would be used in a schematic.
    • Perhaps reshuffle pins (a popular example are XIN and XOUT for a crystal. Its useful to space them by 200mil so Crystal_Small fits between the pins)
    • Correct ordering (e.g. numbered GPIOs)
    • For multiple units: does the split make sense?
  8. Metadata
    • Matches the Datasheet, is consistent with other parts in the lib
    • Package name at the end of description for standard packages
    • Keywords exist and make sense, perhaps additional keywords required
    • Datasheet link exists, page-number anchor if applicable
  9. Footprint
    • Exactly matches datasheet (check drawing)
    • Datasheet matches kicad-footprint pin numbering (there are vendors that don’t follow JEDEC)
    • Filter matches, pin-count not included (unless required)

Perhaps I will make a similar list for footprints in the future.

El-cheapo China DMX LED Spots

I recently got me a set of 4 DMX-Controllable LED Lights of ebay for 35€ including shipping.

ebay-listing picture
ebay-listing picture

But they are rather dimm. The article page states

Power Consumption: 15W
LED: 12 pcs * 1W LED (Red*3, Green*3, Blue*3, White*3)

So, lets open one up and check the insides.insides of the led fixture, a multimeter

When setting all LEDs to maximum (RGBW) the multimeter reads 185mA DC. At just 12V thats not barely enough. Interestingly though, setting it to AC+DC mode reveals a stunning consumption of 340mA, thats almost 4Watt.

But wait, why is there even AC voltage when everything is turned up to full brightness?

Scope to the rescue!

I put a 1Ohm resistor in series to measure current, so 1mV -> 1mA. The voltage across the LEDs is always 12V, as output by the PSU.

scope showing the current waveform for the blue led

You can see 478us PWM-Period with a on-time of 126us. Thats a DutyCycle of 26% at 100% brightness. That explains the AC current measured earlier. The peak current is ~275mA.

  • Red: 780mA, DutyCycle 17us/318us -> 0.5Watt RMS
  • Green: 350mA, DutyCycle 108us/480us -> 0.95 Watt RMS
  • Blue: 275mA, DutyCycle 126us/480us -> 0.86 Watt RMS
  • White: 487mA, DutyCycle 98us/480us -> 1.19 Watt RMS

This roughly correlates with the 4Watts measured with the multimeter.

But what about the overall quality? I guess you get what you pay for.

  • The LED PCB is made out of aluminium and is a decent heatsink. But it is rather thin. The LED-lenses are as described and work properly.
  • Plastic case seems nice. No problems here
  • The Control-Knobs are easy to use, the 7-Segment-Display shuts off after a few seconds. Premium feature!
  • No gamma adjustment. 50% Brightness equals 50% (of max) DutyCycle.
  • The DMX In- Out-Port are just connected to each other. No RS485-driver to improve signal quality
  • The internal plugs are JST-XH (clones?), but they saved a few cents by just populating pins instead of complete receptables on the controller board.
  • The PWM-Base-Frequency of red is different than the other colors. WTF?
  • Since no DC is > 25% one would expect that the PWM-Periods are interleaved so the current does not add up. But nope, thats not the case.
  • No resistors in front of the LEDs. So the 3 red LEDs which have a combined Vf lower than 9V are run at the full 12V.
  • There is no sign of any PFC on the primary side of the PSU.
  • The PSUs isolation between primary and secondary is garbage. The feedback-opto has all its 4 terminals pretty close to the primary side. Thats less than 1mm.

Conclusion – Next steps

So this is not as bright as I want it to be. And the PSU looks dangerous. So the next logical step is to fix that. I used a lab power-supply to check if each LED actually can handle 1Watt. The answer is yes, but then it gets hot rather quickly. So some sort of cooling is required.

I think the mod will be made with series-resistors in front of the LEDs so they can run of 12V DC. Then all 4 fixtures controlled by one KaratLight Device. Not sure about cooling yet, running this at 12Watt will be to much heat for the aluminium PCB to handle.

Rant: Why “Atmel START” sucks

Recently I had to work with Atmel START. The basic idea looks promising, a nice GUI to configure the peripherals of your chip so you can start with the actual project faster.
But there are way to many downsides.

It requires a Internet connection

I don’t really understand the whole Idea behind the architecture. It looks like the GUI generates a json which is then send to the Atmel backend that is somewhere on AWS. An archive with source code is generated, downloaded extraced and integrated into the Atmel Studio Project.
There is no offline Workflow. If you want to reconfigure something, you need a internet connection.

Bullshit error Messages

Look for yourself. This is what I got the 2nd time I tried to update a Project. Funny enough, just doing it again made the error go away. Quality software, yay!
There is also the case that the Backend does an Error 500. I have seen this several times, it seems to be triggered by entering weird values into the GUI fields. Like 10Ghz Clock frequency or so.

It is slow as hell

Changing one checkbox takes about two minutes. The loading time of the GUI is already a minute, then the GUI scrolls really slow and is unresponsive. After doing the change, it takes ~20sec until I am back in Atmel Studio and can hit compile.
By now, I have learned to change the C headers directly. But that means also extra work when I want to add another module via START since I need to manually merge the differences between my local files and the generated ones.

The GUI has usability issues

Labes are cut off and are not visible. Why would the Framework set the same Userlabel as the Pin name. If its the same, its redundant.
The Screenspace is not well used. Resizing windows is a PITA because its so slow.

GUI fields description

Here are two prime examples. Why does anyone include a description like this. I can tell this by reading the field name. How about “Checking this box will change the way the divider is calculated. Unchecked means divide by N-1, checked divide by 2^n-1”.

GUI fields functions

The clock divider for DPLL XOSC input does not work inside Atmel START. So all the other modules assume a wrong clock frequency. However, the chip does behave as predicted.

There is also no hint that this divider only applies to XOSC, but not for the GCLK input.

To make tings worse, there is a field called “Reference Clock Source” and one called “Reference Clock Selection”. Really? It doesn’t even make sense after looking into the data sheet.

GUI fields function, again

If there is a checkbox, that disables a function, also disable all the related fields so its obvious to the user that they have no function.

This feature is implemented for most modules, but is missing for the USB Configuration. So the user has no visual hint why the USB descriptors are not working.

Clock Configuration

This is actually pretty nice, to have a schematic on clock distribution. Good start. Next, please add the respective frequency of each clock on its configuration page. The values are already calculated, I can see them in the clock selection dropdown of the usb module. Why not just display the frequency on the GCLK or OSCCONTROL page as well?

There are bugs

Well, all Software projects have bugs. But in this case it really sucks. Imagine spending an hour to get clocking right because the GUI is broken. Then finally hit compile and the code hangs during USB initialization. Looks like the DFLL vs. DPLL decision making does not work. Had to patch this by hand, now its good. But again, I need to redo this patch every time after project reconfiguration. Great.

There is no central place for the code, and thus on issue tracker

So, I have spotted a few bugs. That happens all the time, no big deal. Usual workflow is to create a patch and do a pull request. But not with Atmel Start. There is just nothing one can do. Every other user has to find and fix that issue again and again.

Missing functionality

A few things that hit me on the first day
– NOR-Flash driver only talks QSPI, not ‘regular’ SPI
– There is no CAN driver, only a example for a CAN cip attached via SPI. No use for a CPU with a buildin CAN
– The IP Stack has only LWIP 1.4, even though LWIP 2.x is stable. So no IPv6 support

I can’t go back to ‘regular’ ASF

It looks like newer chips are only supported via START. So I can’t go back to the ‘just have some code and makefiles’ approach of ASF. There is just no support in ASF for newer chips. Now I am stuck with this START shit.

 

Unfortunately this is a work project, so I can’t choose to have a different CPU. And supporting it in libopencm3 is nothing my employer is willing to spend any resources on.
So I am out of options and stuck with this shit. Even though there are some nice new features, like the generic-io-API for serial connections, … this does no make me happy.
Dear Atmel/Microchip: Please just put the libs on github and attach some Makefiles for ease of use. I promise to send patches 🙂

Diesel engine cooling-radiator ghetto repair

For this years EMF camp I was traveling together with the belgian embassy. We had two busses filled with people and material to drive from belgium to the campsite and back.

One of the busses had a blown tire on our way, that was fixed by fitting the spare:

Blown tire

On our return trip however, we had a major issue. The radiator was leaky, as seen in this picture. The water on the road used to be in the cooling system.

busWe did discuss how to fix it. One option was to just put an egg into the cooling liquid, in the hope that the protein would coagulate and stop the leak. But that is a process we can’t control, so we switched our focus to other methods.

Next up was soldering. We had lots of solder-equipment with us, after all we were coming form a hacker-camp. But soldering on a heat-sink is doomed to fail. Perhaps we could have done it with a propane torch, but we did not have one with us.

All that was left was to glue it. I had some 5-Minute-Epoxy at hand. First we drained the radiator and dried it with the hot-air. Then some cleaning using wire-brushes and isopropanol was done. The epoxy was mixed and stuffed into the radiator with tootpicks and other pointy objects, then heat-cured with the hotair for 30minutes.

This is how it looked after the curing:

radiatorIts messy and ugly, but it did seal the leak. I did expect that it would still leak a little, but to our surprise it was perfectly sealed. The cooling system was even able to build up pressure again.

With that repair we made it back over the canal back to belgium 🙂

A USB Interface for a Mitutoyo Caliper

I am in need for a z-measurement device for my cnc. So I checked ebay and got me a used mitotuyo depth gauge for ~60€. It has an ‘SPC’-Interface for digital readout. Fortunately there is some information on the Web on howto access that interface.

IMG_2912.small
DIY connector

I didn’t want to buy an expensive Mitutoyo-cable, so I decided to solder on my own connector.

Pinout is:
1. GND (red cable)
2. Serial Data Out (OpenCollector)
3. Serial Clock Out (OpenCollector)
4. (unused)
5. Request In

The USB-Conversion is done by a tinymega microcontroller board which features an Atmega32U4 CPU. With the LUFA USB-Stack  it presents itself to the host as a virtual serial port.

The implementation of  the SPC-Protocol decoding is pretty straightforward. Send a request on one pin, read in data via SPI. I chose to do all of this in software with one interrupt (not using the SPI peripheral of the CPU). You can see my implementation here on github.

caliper + tinymega
caliper + tinymega

Now all that is left is to hook it up to linuxcnc. I haven’t done that yet, but most likely it only requires 10 lines of python to generate a HAL-Module.

WS2812 LED Pixels with ola using SPI

Controlling WS2812 LED-Pixels from an Raspberry-Pi can be done. Other people have done this before: https://github.com/jazzycamel/ws28128-rpi/
My approach is different, but not that new either. I already implemented similar code for the Lightpainting-Stick-Clone.

To get the required timing with the SPI we can output some patterns to make it look like the WS2812-Protocol.

ws2812_spi_transfer
The yellow line is MOSI (DIN). The 50us Reset is visible on channel 2.

ws2812_spi_transfer_close
Closeup of the actual timing. This image shows the first 7 bits (1000010)

 

However, there are some issues as metioned in the inline-comments. At first it seems like the code does not work when sending dmx-data with ola_dmxconsole. Once there are more changes in a short period of time, the pixels start to react. My guess here that this is related to the scheduler of the kernel. When as the kernel switches tasks the SPI output-stream gets interrupted, thus making the timing invalid. I will investigate this further.


void SPIOutput::IndividualWS2812Control(const DmxBuffer &buffer) {
  /*
   * This is an hack!
   *
   * Basically the RaspberryPI cant drive WS2812 Pixels because they have
   * some strict timing requirements.
   * Using the SPI-Module we can emulate those pulses.
   * This will only work if the SPI-Module outputs all data in one consecutive
   * stream without any pauses. More recent versions of the Raspberry Kernel
   * seem to implement DMA for SPI which makes this possible.
   *
   * WS2811-Chips have similar timings but not exactly the same as WS2812.
   * Some sources say the most important part is the total period-time
   * of one bit. There are lots of descriptions of WS2812-timing requirements
   * out there, one of them is: (with +-150ns tolerance)
   * 0-Bit 0.25us high, 1us low
   * 1-Bit 0.6us high, 0.65us low
   *
   * Running the SPI at 4Mhz gives us a pulse-width of 250ns
   * Using a 5-bit pattern we can emulate those timings
   *   0-Bit: 10000 (0.25us high, 1us low)
   *   1-Bit: 11110 (1us high, 0.25us low)
   * Those values are not an exact match, but they seem to work for both
   * WS2812 and WS2811 in high-speed-mode.
   *
   * We need to send 8 of those 5-packs for each byte. Those 40 bits are
   * precalculated and stored in a lookup table.
   *
   * To issue an reset, the data-line needs to be low for 50us, thats
   * 200 bits, or 25 bytes. For safety, we will send 27 bytes.
   *
   * Connect the Data-In-Pin of the LEDs to the MOSI Pin of the SPI-Module,
   * ignore the clock Pin.
   *
   */
  const uint8_t reset_bytes = 27;
  const unsigned int first_slot = m_start_address - 1;  // 0 offset
  // We always check out the entire string length, even if we only have data
  // for part of it
  const unsigned int output_len = reset_bytes + m_pixel_count *
                                  WS2812_SLOTS_PER_PIXEL * WS2812_SPI_LUT_LEN;
  uint8_t *output = m_backend->Checkout(m_output_number, output_len, 0);

  if (!output)
    return;

  // set the reset-bytes to zero
  memset(output, 0, reset_bytes);

  // loop over all pixels
  unsigned int output_pos = reset_bytes;
  for (uint16_t px = 0; px < m_pixel_count * WS2812_SLOTS_PER_PIXEL; px++) {
    uint8_t c = buffer.Get(px + first_slot);
    // now output 5 bytes from the LUT
    for (unsigned int lut = 0; lut < WS2812_SPI_LUT_LEN; lut++) {       output[output_pos++] = WS2812_SPI_LUT[c * 5 + lut];     }   }   m_backend->Commit(m_output_number);
}

I pushed that code here: https://github.com/cpresser/ola/tree/ws2812-spi

This is the config I used:

base_uid = 7a70:00000100
device_prefix = spidev
enabled = true
spidev0.0-0-device-label = SPI Device - spidev0.0
spidev0.0-0-dmx-address = 1
spidev0.0-0-personality = 9
spidev0.0-0-pixel-count = 10
spidev0.0-backend = software
spidev0.0-ports = 1
spidev0.0-spi-ce-high = false
spidev0.0-spi-speed = 8000000
spidev0.0-sync-port = 0

Demo time:

PCB fixture for applying solderpaste

I have done a few PCBs using the reflow  process. To apply the solder-paste using a stencil one requires some sort of fixture to hold the PCB.

So far I helped myself with other PCB Material which I glued on the table to get to the same height. This is okay when only one PCB needs to be made. However, when doing multiple PCBs on after another, the position needs to be constant for every board.

So I designed a simple spring loaded fixture to hold the PCB in place. Its made out of 1.5mm acrylic.

PCB fixture springs

Scara Robot Repair – Learning stuff the hard way

Turns out the drives of my Scara Robot are not velocity-mode drives but torque-mode drives instead. Setting the drive input to a constant voltage results in constant accelleration. I learned this the hard way by crashing the robot :-/

Even though I had it fixed on an Europalette it managed to fall on its side. Second lesson learned: even ‘small’ a 200W drive can turn the whole thing in a fraction of a second. Hitting the floor broke some pieces. But see for yourself:

B-Arm and Z-Motor-Plate destruction
B-Arm and Z-Motor-Plate destruction

Those parts are both made out of cast aluminium. I do lack the equipment and skill to weld, so I asked a Friend of mine to do it. However, even with his long time experience he wasn’t able to fix the parts together. At first I got desperate and tried hard-soldering the Z-Motor-Mount. But even using two torches I wasnt able to get the part hot enough to accept the solder.

Z-Motor-Plate fixed with clamps ready to solder
Z-Motor-Plate fixed with clamps ready to solder

As a last resort I deceided to glue the parts. Fortunately my sister works as a postdoc and is an expert for aluminium epoxy bonds. She did some rought calculations for me and helped select the correct adhesive: 3M Scotch-Weld DP490.

I prepared the parts by grinding away all paint and about 100microns of the aluminium. The last step helps because cast aluminium has different properties on the outer layers compared to the inner bulk material due to the casting process. I also cut some reinforcement plates from 6061 Aluminium. Then I cleaned everything several times with water/soap and acetone. Everything was clamped down on a clean plate and glued together in two steps: First the two broken bits were fixed together. After curing the residual glue was removed by grinding, then the reinforcement plates were glued. To improve the curing process I put a box over it to trap the air inside and heated everyhing which a hot air gun to 80°C. Unfortunately I didnt take that many pictures of the process:

After that, I did some cosmetics. With a lot of car putty, grinding and even more putty and finally a red finish the part looked like this:

Fixed B-Arm with W-Motor already mounted
Fixed B-Arm with W-Motor already mounted

 

That concludes the B-Arm. Fixing the Z-Motor-Plate was basically the same. Here are some more pictures:

That concludes the repair. I will cover the mechanical and electrical rebuild in a seperate Blogpost.

Hirata AR-c270 Scara Robot Retrofit – Part1

Hirata Scara Robot
Hirata Scara Robot

Recently I bought a Scara-Robot from Ebay. Its an older model with an outdated control. Motors, servos and encoders are in working condition. Using the Teach-Pendant I can move the Robot around.

My plan is to retrofit the control using linuxcnc. All IO will be done with a MESA 7i77+5i25 combo. I will try to reuse everything besides the original control.

There was quite a lot of documentation included in the Ebay auction, but most of it only covers software. No hints on the pinouts of the servo amp. The company producing the robot still exists, so I gave them a phone-call to request additional docs. I bought the manuals they offered me, but unfortunately they didn’t help at all. So I had to take the thing apart and try to reverse engineer the important parts. My findings so far are all in this 20150422_doku_hac214a.

servo-amp
HPC-53IDI Servo Amplifier

There are some diagramms for the motor- and encoder connections. And yes, the encoders produce a nice A/B-Signal:

As a next step I will test on of the amps standalone. Hopefully the info extracted so far is okay. Running the amps in velocity mode will make it easy to connect everything to the 7I77.