Skip to content

Output Devices

Description

This week we use our own PCB to make a device do something. WE start with a group assignment.

Group Assignment: measure an output device.

We are going to measure the noise on a servo motor because this has the interest of Erwin. I trust him fully this is indeed interesting. WE connect the servo to an arduino, have a little program on the arduino that turns the servo and then we measure the signal on the GND for interference.

The arduino is providing 5V to the motor. But using PWM it is going to modulate the amount and that is then used by the servo motor to determine position.

Erwin quickly wrote a bit of code to make the arduino do this.

The most interesting part of this assignment is written down by Paula.

Assignment 2: make a board that can hold an output device.

Considerations and ramifications.

Or: how do I even start...?

Henks' advice is:

  • assume you are going to use the ATtiny412
  • check what that needs (power, gnd and a capacitor)
  • decide on an output device (LED for example)

Now my big question mark is how to go from there. I guess I just need to read what others did in order to better understand the paths to follow. So my week started by reading. In the Research and relevant links section below you can find the pages of other fabacademy students from whom I learned a lot.

After doing some reading I take most of the advice from Phil and Nadieh. They both started by writing down

  • what they wanted their board to do
  • the stuff they needed to achieve this
  • what MCU would be the best fit for this

And then they worked from there. I guess I will follow in their steps and repeat their recipe from input devices week to do my output devices week. Of course I should pay extra attention to their mistakes as I have the luxury of being able to prevent these from happening again.

Design criteria.

Considerations

In the input devices week I really needed to search for possible relevant input that I could use for my end project. But for output devices this will be a lot easier. My final project will need to communicate something to its viewers. So a clear, distinguishable output is super relevant.

Still, as my input device week was an utter disaster, I could try to squeeze some sort of input device into this board, so I can also tick of that box...

Also, when I was summoned to present in Neils review of input devices (presentation start at the 2:19 marker, tips from neil start at the 16:00 marker), he talked about networking and how that could help me drive the different parts of my end design. As I think this has something to do with I2C I'd like to see if I can also experiment with that, but I can also save that for networking week...

So my design criteria for my output devices week are:

  • An RGB LED that can be told which colour to shine
  • LED colour changes happen on the basis of pre-defined timed events.
  • the LED turns on based on detected motion (doppler sensor)
  • Powered by a phone adapter (USB)

Now how to start...?

Probably starting with one of Neils boards again is one of the safest ways forward.

On the output devices page there is a nice board that has an RGB LED, with all milling instructions next to it.

But alas; I have to design me own...

This is the RGB LED board. It runs on 5V.

This is the doppler radio board. It runs on 3.3V

Taking Henks' advice. I first check if the doppler also functions if there is 5V supplied to it. This would make my board design easier... supposedly.

I use an Arduino Genuino that is lying around in the lab to test this.

I use the manual by Floris Wouterlood to see if this works.

There is also an interesting paragraph in there that already seems to answer my question:

The breadboard power supply has a 3V-5V switch. If this switch is in the 5V position the RCWL-0516 works fine. If however the switch is set in the 3.3V position the RCWL-0516 goes into ‘error signaling mode’, that is it generates a continuous 2 seconds-ON, 1-second OFF pulse at its OUT pin. This leaves the impression that 5V is minimum operating voltage for the device. This 5V can be supplied by a breadboard power supply as good as by an Arduino. The 5V pin of an Arduino is capable of supplying 200 mA. This is more than sufficient for an RCWL-0516 to operate (20-30 mW output radiofrequency power).

Using the sketch from that manual (without the LED references) gave me satisfactory results: the doppler detected motion without any issues.

This means that the entire board can be powered from 5V and that the following items are needed:

COMPONENT DESCRIPTION DATA SHEET SPECIFICATIONS
RCWL-0516 Doppler radar RCWL-0516.pdf polarity
ATtiny1614 A pin upgrade from the ATtiny412 1614_datasheet.pdf polarity
LED_RGB_CLV1A LED with three colours ds-CLV1A-FKB.pdf polarity
UPDI Header pins To allow board programming/serial communication. polarity
FTDI Header pins For power and to readout serial polarity
Capacitor To stabilize power signal. 1µ
R Resistor Resistor next to for R 1KΩ
G Resistor Resistor next to for G 1KΩ
B Resistor Resistor next to for B 499Ω
General Resistor Resistor that Neil always puts on his board 10KΩ

Design and research

Now that I have a somewhat basic idea of what it is that I should make, I set out to try and see if I can bring it all together.

For this I will have to check the boards that Neil made and understand why stuff in certain places. And also why I would need that stuff as well. Let's see what we end up wth when I move this to KiCad...

I could not find the RCWL-0516 in the Fab library in KiCad. It is in the FabLab Inventory list. But then I figured from looking at Neils picture that I won't need the footprint of the entire device in my schematic; just the connector.

Carefully examining both the board and the components I figured there is a 5 pin connector on the board that will help connecting the doppler.

And that one can be found in the Fab Library.

After I put all the parts in place, I quickly see that there is actually not enough pins on the ATtiny412 to connect all the parts... So after consulting with Henk I move to the Attiny1614 instead.

Now I need to find out:

  • what pins can I connect the R2, R3 and R4 to that will tell the LEDs to light up
  • what pin can I connect the OUT pin to from the doppler
  • what pins can I connect the TX and RX of the FTDI to?

LED pins

Let's start with the LED pins. If we look at the schema of Neil, we see that these are attached to the pins PB0, PB1, PB2 of the ATtiny45.

Now if we consult pinout guide of the ATTiny45 we can see what these ports do:

And we can see if we can 'map' these to the ports available on the ATTiny1614 using the pinout guide of that MCU

Things that become clear from looking at the pinouts is that:

  • All pins, except VCC and GND in the t45 are labbaled 'Port Pin'. This could mean Digital/Analogue
  • Tx and Rx pins are labeled for the t1614; but are we sure how to connect them to the FTDI?

NOTE

As for the TxRx question I made the following descision: as long as we have to connect TxRx parts on the same board we connect RX to RX and TX to TX. If you make a connection from one board to another then Rx goes to Tx and Tx goes to Rx.

This makes total sense to me. Now lets see if we can convince the rest of the world to follow this great idea.

I decide to connect the RGB pins to PA3, PA4 and PA5. Also because these ports have a tilde (~) next to them in the pinout schematic. This tilde means that the pin support PWM (Pulse Width Modulation); something that is needed to dim LEDs.

Doppler pin.

Now I can do the same for the OUT pin on the doppler.

This pin does not need PWM, but as we still have one available and It won't hurt to use it, I decide to go for PB0 for this pin.

RST pin.

Then the only pin left that was unclear is the RST pin, but accorinding to the pinout schema, that is the same as UPDI. So I connect them together.

Finalizing the schema.

As a final action I add blue crosses to the pins that I will not use. I saw that Phil did this and he said that it helped them make things less confusing. Sounds like something I could use.

As detailed in week 6 we can then proceed to draw the footprint of all the components.

Annoying enough I find that some footprints give errors. This turns out to be because I uses items from generic libraries that are also installed in my version of KiCad. I should try to use the fabacademy library whenever I can...

After I placed all the components, I did a little bit of twisting and turning, shuffling and shoving to get stuff in a position where as few white wires are crossing each other as possible.

Closely inspecting the drawing gave me one thing to ponder about: is it correct that the 10K resistor (in the white circle) is connected to UPDI?

I made the conscience descision that these should go together based on this schema:

But I am doubting this is correct... so I take it to the ~General channel on Mattermost. And sure enough there is a prompt answer by the Adrián:

Adrián Torres: 20:09 For the new generation AVR you don’t need this resistor. Only you need the 1uF capacitor for the VCC and GND.

So I can just chuck that resistor out and rejoice over the fact that now there is a component less to worry about.

Route tracks.

Now it is time to route tracks. I have found this a somewhat frustrating job. In week 06 I was even so lazy that I used the autorouter. I am not going to do that now (so said he at 20:27 sharp. future self might have different plans ha ha ha)

After some research online I found that it is not so hard... Altough I find it really a pity that you can't freely drag items around after you painted the copper traces...

Here is the current result:

Which looks even nicer in 3D:

And with that it seems as if I will be ready to mill tomorrow morning. here are the files I'll need.

Soldering the board.

Programming the board.

Now that we have the solder in all the right places we can program the board. FTDI is connected to one side to provide the power. UPDI is connected to the other side to provide the bits. (both boards and cables kindly provided by Nadieh as mine were at home.)

I first try to upload a generic Hello World program: that works.

I then try to upload Adrián Torres Hello Radar sketch. That does not work.

Suddenly the uploading of sketches seems to fail at random points in the hex file writing action... either here:

Writing from hex file...
Writing flash...
[========================================          ] 25/31Traceback (most recent call last):

or here:

Writing from hex file...
Writing flash...
[============                                      ] 8/31Traceback (most recent call last):

And sometimes it does not start at all...

My debugging consisted of cycling home, having a power nap of 10min and then trying again with a different UPDI. That worked...

Writing from hex file...
Writing flash...
[==================================================] 31/31
Verifying flash...
OK
Verifying...
Verify successful. Data in flash matches data in specified hex-file

Now I am first going to try to get the LED blink using the build-in blink program. I also get some help from Adrián (again) and find out that the orange boxes in the pinout schema are very important: they contain the numbers I should use in my sketches. Somehow I have missed this so far.

So, never forget:

  • Red LED pin = 10
  • Green LED pin = 0

  • Blue LED pin = 1

  • (and Radar pin = 7)

This is the sketch I use to test the blink

Weird problems occur.

  1. The blue LED does not turn on.
  2. The Red and Green LED stay on even when they are not called in the loop and are just initialized in the setup.
  1. The blue LED does not work
# Hypotheses Debugging Solved?
1 I assigned the wrong pin Careful checking of the pin number 0
2 The solder is wrong Some testing with the multimeter reveals that the solder is maybe not as good as it should be, but funny enough, using the multimeter does turn on the LED. I decide to resolder all the points between the ATtiny and the LED 1

  1. The Red and Green LED stay on even when they are not called in the loop and are just initialized in the setup.
# Hypotheses Debugging Solved?
1 It is not a bug it is a feature it poses no issue to continue with the radar 1

The Radar

The radar spits it data towards pin 7 of the ATtiny.

I soldered the radar to the board and use Adriáns sketch to read out the board.

Sadly, the serial connection tells me there is always something moving. I am not sure if there is stuff in the vicinity that is distorting the image... but as far as I can tell, there is also a 1 when everything is completely still...

  1. The radar always detects motion according to the serial output in Arduino IDE
# Hypotheses Debugging Solved?
1 There is a problem with the soldering Use the multimeter to test. I find out that indeed the solder of the VCC and OUT are connected. I desolder the board and connect three pins to it. 0

NOTE The black plastic that holds the pins together also melt when it is too hot. The melt temperature of the plastic is annoyingly close to the melting point of solder... In the top of the picture above you can some pins that got deformed in this process

# Hypotheses Debugging Solved?
2 The new connection has the same problem. Maybe there is more movement in my are that I am aware off I kill all music, lights, static generators, whatever... 0
3 There is an issue with the connection still I disconnect the radar from my board. Weirdly enough the serial keep spitting out 1's 0
4 There is an issue with the code. Let's try another radar sketch. 0

# Hypotheses Debugging Solved?
5 There is nothing wrong with the radar, there is nothing wrong with the code. There is something wrong with my board... Test with the multimeter and I find that VCC and OUT make contact... 1

So the problem is that the VCC and the OUT of the radar pin are connected. Of course this causes the OUT pin to be always on. Still it is funny that seems that this shortcut did, so far, not burn the board or the radar...

Closer visual eximination of the board reveals that there is indeed a place where two paths touch each other, but where they should not:

In the schema that corresponds to this place:

(upside down for consistency)

Now the question is if I can brake this trace w/o having to unsolder the ATTiny1614... Answer: I can't. So I had to remove it.

I then used a little sharp knife to destroy the connection that should not be there.

And then resoldered the ATtiny1614 in place and made another visual inspection if things were fine

Checking with the multimeter afterwards reveals that indeed there is no longer a short cut, and, even more important: I could now connect the radar again and see that indeed the values now change depending on my movement.

Little side step.

As detailed above, I first thought that the issue lay with the way I soldered the radar on the board. It turns out that was not the case: the problem lay elsewhere. But because of this, I removed the board and put pins in place, which caused their own problem (the melting plastic parts). Also, the radar has holes, in the holes the solder got stuck and I had some issues thinking of another way to re-attach the radar to the board.

In the end I figured that having the radar soldered to the board was also not so nice, because I could not attach other input devices; pins are better.

And I soldered three wires through the holes on the radar by pushing the solder iron from below and the pin from above on the hole. This way it could melt a way through the solder and get stuck in place. I probably should cut them at the bottom...

Bringing LED and Doppler together.

Now I want the LED to be RED when there is no movement and Green when there is movement. I do not know what I want to use the blue for... suggestions are welcome...

My final sketch can be found here.

Final result:

What I have learned

  • Always check all your traces after milling.
  • Never assume you found the error on first try.
  • Blame the soldering

Pages by other students: