Steve's Build Log

I had a rough start as I downloaded one of the original archives. This install would throw an error when clicking on the Tools menu. Apparently the archive was updated shortly after the release. I downloaded it again and now it is fine. That was the only major issue.

When opening an existing schematic, I did have a bit of a doubt. I get the dialogue to re-map the symbols. My first fear was what that would mean in 4.0 - symbols suddenly appear in a different size and things don’t quite connect any more. From a brief look around, it seems the best is to accept the defaults. I have not looked into the details yet to know any better. Needless to say, accepting the defaults for the couple of projects I have tried this on has not shown any surprises.

For a new project like the Blinky, it went smoothly. The only thing that lost me was the renaming and re-locating the OpenGL option for in Pcbnew. The hot-key has not changed, just the name. It used to be under View. But they are now located under Preferences.

Preferences_5

I found the explanation and now it all makes sense. Legacy (F9), the old layout canvas and will be removed at some stage. Modern Tool set (F11), is the preferred canvas and is renamed from OpenGL. This name had no real functional meaning with respect to the Pcbnew. The Modern Tool set Fallback (F12) is in case F11 does not work i.e. problems with the graphics drivers.

Once that was understood, it was clear sailing. I also noticed there is an “add vias” tool. This really simplifies things like via stitching as I don’t have to create a special footprint for the purpose.

Vias_5

There is more to explore in Eeschema too… a Symbol Field Editor in speadsheet format where it looks like the component values can be updated. This will be handy for making corrections etc before creating the BOM. One of the reasons I have never really used the BOM feature that much is the back and forth making corrections.

Thanks Steve! Good to hear, my sense of trepidation was holding me from upgrading.

Did you uninstall 4.0x or just do an inplace upgrade?

2 posts were split to a new topic: KiCAD 5 Changes

I thought @RobertBonham post would be better placed as its own thread in the Reouces area

@mikef I pretty much did an inplace upgrade.

I thought I would try my hand at writing a script for KiCAD. I created a small script to archive the F.Paste, B.Paste and the Edge.Cuts layers to a zip file for uploading to OSH Stencils. I have posted the scripts to my GitHub Repository. I found I needed to create two versions of the script as I had some issues working with External Plugins in KiCAD 5.0, Windows 10.

On Windows KiCAD - 5.0 Stable Release, I only have the “Tools->Scripting Console”. The script can be ran from there. I also have a nightly build on Ubuntu (virtual environment). This install has the “Tools->External Plugins…” menu as described in the documentation.

A quick chat with our friends at KiCAD Info indicates that the menu option should be available for Windows in 5.0.1

Both versions will create a ZIP file in the project directory with the name

{project_name}_stencil.zip

This last few months, I have only managed to do a couple of not so serious boards like the “Thank the Maker” Badge


Which is actually an exercise in custom/complex board design inspired by reverse mounted SMD LEDs.

I had to do a second revision to make the eyes blink once every 40 or so seconds using a 555 timer. I was caught out by not reading the datasheet (again). The 555 stops working below 4.5V so the 3V button cell was not going to cut it. Not to be defeated, I modified the cell holder to accommodate two cells. Now it works fine and can last up to 6 or so hours continuous running.

1 Like

I have seen a circuit popping up now and again, particularly in the kits from ELV where they use a Gold-Cap (Super Capacitor or Electrostatic Double Layer Capacitor, if preferred) to provide a small backup supply to either enable a real-time clock to keep time during times of no power and in one case to enable time for the micro controller to clean things up before going into sleep mode.


For a project I am working on, I am keen to try this out. But before I race ahead and start building it in, I figured a more systematic approach would be to create my own Dev-board so that I could at least experiment with it in isolation to understand things like

  1. How long will this last? and understand the power that can be delivered
  2. Learn about the various sleep modes and how to wake from them.
  3. How the ancillary part values can influence the behaviour.

I’ll be using an ATTiny20 as the microcontroller - one of my design constraints is to use up what I already have in stock. I have also broken out the GPIO to LEDs and Pin headers. This way I have a choice to use LEDs as indicators (and a type of programmable load) or use the for any other purpose as I figure out some tests.

I like to use theTag-Connect adaptors for my programming headers. I have opted to use the Legged version of the Tag-Connect on this board since I reckon it will be simpler to work with in the end than the No-Leg version. I was at Embedded World last week and had a chat with the chap from Tag-Connect. He gave me the idea to make the Tag-Connect Pads through-hole (using OSH Park’s minimum hole size). I am curious if this is going to work or if there is an issue with the annular ring! For routing, it certainly helped being able to utilise the bottom side to get around the “leg holes”.

On this board, I am also trying my hand at Castellated Edges.

2 Likes

Since the last post, I had to respin my Gold Cap Breakout board after realising an issue. I have finally been able to assemble this latest revision. Inspired by one of @ChrisGammell’s videos - I reduced the size of the Solder Past holes - just slightly. I realise there is an issue for fine pitched parts but in this case it was all good and I am very happy with the re-flow efforts. I did not have to apply any bodge or retouch any of the joints. The whole thing just worked! :slight_smile:

!

I am also happy with the Tag-Connect programming header. As mentioned in the previous post, I changed the footprint to use Through-Hole vias for the pin-pads. This enabled some routing on the back side of the board, since getting around those “leg-holes” is quite tricky. The through-hole pads also have the added advantage of preventing a probe from slipping when using it as a test point.

I have been able to program the ATTiny20 with no issues at all. As a first cut and just to test that everything is working, I have setup one LED as a “heartbeat” and the rest of the LEDs as a rough and ready bar indicator to show the relative voltage level of the supply/Gold Cap. The next steps will be to work out some tests understand how long these will last based on the load.

3 Likes

Over Christmas I was thinking of other kitsch ways to use LEDs and thought of creating an animated “Tree Bauble”. At first I was imagining all sorts of advanced setups such as micro controller based animations. As the idea developed, it seemed to get simpler and simpler where I decided to use the slow self-blinking LEDs.

At one point, I was thinking to use flexible boards to attach some LEDs to. This gave way to an even simpler approach - soldering the LEDs directly to the “End Cap” boards.



I could not wait for the arrival of the intended 2512 sized current limiting resistor, so I just soldered a through-hole resistor onto the pads instead - another simplification.

This is just the first attempt. Something needs to be done about the power supply. The 9V battery is too big and heavy.

demo video

1 Like

It has been a long while since doing any sort of write up. I have been more trying things out and experimenting rather than actually building anything at the moment. I did have a good look at the INA219 “Zerø-Drift, Bidirectional Current/Power Monitor With I2C Interface” and created a bit of a write up about my test and what I found.
The fun part was to brush the dust of the Current Sink or Swim. It was a great help in setting up a dummy load for the tests.

I had seen this come through via email, that was a great post! Was going to ask on there, do you have any cost contraints on your measurement system? If so, do you think the INA219 will be a good fit?

Thanks Chris,

I consider this entire effort a learning exercise, so I don’t have any real cost constraints as such. But I do see where your question is coming from since the INA219 is not cheap (~2.00€ for one) I think if I had cost constraints, then I would need to closer look if the INA219 should be a good fit or not.

Though there is a unit cost for the device, there is also a saving. In previous experiments, I had used voltage dividers to measure just voltage using the ADC in a MCU. I was never happy with the results since it was hard to get a value that was truely indicative over a range of voltages. All the engineering for the ADC side for this purpose is done on the INA219. Coming from the software side, I am attracted to the notion that I can literally use it like I would a 3rd partly library. Just ask it for the information and not have to deal with the detail. The INA219, though expensive, gives me confidence in the data collected and now I can concentrate on the other aspects.

This was all inspired by a mate who has a farm and has been exploring some of the remote sensing ideas. I have no ambition to sell this. I am sure there are already plenty on the market now. I took this challenge on as a way to first, learn about putting such a system together but also to show my friend what he can be looking for when the salesman comes knocking. I think if I were to be looking at producing a lot of units, then cost would start to play a bigger role.

Nice build log! I have to agree that the mechanical design is often the most frustrating part.

1 Like

I had a go at using Test Driven Development when creating a small gateway using a Raspberry PI, XBee modems and Python. I wrote about the approach in my blog Creating a Gateway Node using XBee and Test Driven Development. Now I have a reference project where I can create the sensors and see the data collected immediately in the web application rather than watching a serial console.

1 Like

Dev board for the ATmega1608

I wanted to experiment with the suitability of the ATmega1608 for use with some other projects. Rather than getting a development board from Microsystems, e.g. the ATmega4809 Curiosity board, I believe creating my own board helps me understand what is involved to physically apply the MCU and not just the programming of it.

One of the criteria for selecting the ATmega1608 was the two USARTs. My idea was to have direct access to the additional USART1 via USB as a means to write diagnostics during development. This leaves USART0 free for the application. Taking the example from the Central Command - a former CE project, I added an FT232RQ to the design since I had some in stock. I have a set of Tag-Connect edge connectors and wanted to finally try these out too so I added a castellated edge for the ISP connection.


Assembly and Testing

I am very happy with the reflow and bringing the board up showed there were no shorts etc. and is able to be powered from the USB or the 5V input. There is a small problem when connecting the Tag-Connect to the castellated edge connector - the mechanical aspect is perfect and I think OSH Park did a great job with the castellated edge. However, I fell for the bottom side view on the diagram of the Tag-Connector data sheet and so the connection to the UPDI pin is on pin 6 instead of pin 1. The connector is keyed so connecting upside down without damaging the connector is not possible - I visited Embedded World again this year and had a chat with a Tag-Connect representative. He did say they have some universal connectors [tongue in cheek]. Someone was asked to help with the assembly and filed off the keys on some connectors, thinking they were artifacts left by the manufacture/mold process. So modifying my connector is an option.

Luckily, I had broken out all the pins on the ATmega1608 and I could connect the ICE programmer using the squid connector. With that configuration, I am able to successfully program the MCU when the board is powered from either the USB or the 5V supplies.

ATmega1608 ICE AVR
GND 2
UPDI 3
Vcc 4

Verifying the USART1

Connecting the board to the USB port on the PC, it makes all the positive signs of a successful connection. Inspecting the device manager, all looks good there too. The problem is when writing to the USART1 from the ATmega1608, nothing is appearing on the terminal program on the PC.

DeviceManager

Connecting an additional USART-USB adapter to the ATmega1608 Tx pin, I am getting the sent messages and I can see that they are arriving at the Rx line on the FT232RQ but nothing is showing on the USB side.

I am confident I have not mixed up the Rx and Tx. The only thing I am not confident about is the configuration of the FT232QR itself. Unfortunately, I did not break out these pins to make it easy to probe around on them. After studying my schematic I did notice (not sure why) I did not pull up the ~RESET line which is connected directly to the ~RESET line of the ATmega1608. This pin is also broken out so I tied this high as an experiment, but this makes no difference to the behavior.

Conclusion

I am very pleased with how the board turned out irrespective of having the ISP the wrong way around. The only puzzle to solve is why the FT232RQ is not working as hoped or expected. This does not hold me back from continuing to work with this board but it is disappointing that I am unable to directly use this chip at the moment.

I am thinking that in a subsequent experimental board, it would make sense to also break out all the pins on the FT232RQ to make it easier to probe them or add in extra configuration connections.

1 Like

Hi Steve, please say if you’re just logging here and not interested in comments/ideas but I recently fell foul of a clock issue in a modern AVR UART. So have you checked your baud rate is correct coming out of the ATmega1608, in terms of a rate that the FT232QR is expecting? In my case, I was able to configure the UART with a non-standard baud, which when combined with the clock issue produced a standard rate (I was unable to address the clock issue closer to its source).

Thanks Simon,
I am happy to take advice. I should have added that I was open for troubleshooting ideas as I had tried pretty much everything I could think of.

I connected my oscilloscope with a decode option to the AVR UART Tx pin. It was able to decode the message OK. The external UART to USB adapter is also able to pick up the Tx line OK. That lead me to assume all is OK and that I am missing something in the setup of the FT232RQ.
When you say clock issues, this makes me wonder if it would have been better to add an external crystal to the design.

No, I had the wrong peripheral clock settings/dividers, resulting in a 0.8 speed baud - you shouldn’t need an external oscillator. As long as the scope can decode at the expected baud, that’s all I was suggesting.

Have you set the virtual COM port baud rate + other settings in the driver control window in Device Manager?

I have verified the virtual COM port settings as 9600, 8, No parity, 1 stop bit and no flow control. This is what I have configured for the AVR USART1 as well - About the configuration, I am using MPLAB X IDE and configured the USART via the Code Configurator. I have used this before and it has always worked but this is the first time I am trying to communicate directly with an onboard FT232RQ.

DeviceManager_02

I sometimes think there is a continuity issue. The testing I am able to do discounts that theory. The Device Manager reports that the device is working fine and I have R3 and R4 0Ω on the TxD and RxD lines. Probing those shows the signal is getting through to the RxD on the FT232RQ.

The only thing left was the reset line. But tying this high had no effect - in fact, pulling this low causes a reset and enables the FT2323RQ to reconnect (i.e. the indicator LEDs flash, if that is anything to go by)… So I am still not looking in the right spot.

My last thought is to connect the PWREN# (CBUS3) to VccIO which is mentioned for some of the configurations. This is where it would have been nice to break out the non-connected pins to simply test points. Such a small package and fine pitch makes it hard to bodge.

I was not able to solve the issue with the FT232RQ and decided that this was a distraction from what I was trying to achieve. I have not given up on it but will take a closer look some other time.

I decided to do away with the USB chip and replace that whole section with a socket connector where I could then simply plug in a USART to USB adapter. I have a couple of UM2102N from ELV on hand and setup the connector so it plugs straight in. In the end, this saves quite a bit on the BOM. The only purpose I had for the USB was for printing messages during development i.e. while using Unity for tests. So this approach makes more sense.

Now I have the setup I was looking for. The programmer connected at one end and the USART to serial the other. There was one issue with the Tag Connect Edge-Connector. It seems I picked up the wrong version for my setup but this was quickly solved with the Atmel adapter that came with the Atmel-ICE programmer. I could correct the pin mapping and now all is working as expected.