Showing posts with label Arduino Nano. Show all posts
Showing posts with label Arduino Nano. Show all posts

Friday, March 28, 2025

Print your own USB connector

For an index to all my stories click this text.

Sometimes I find something on the web that is so usefull that I want to share it with you.

Powering your circuits.

When testing and building a small circuit with just one or two sensors you can use the power that your microcontroller supplies over it's 5V pin. Both the ESP32 and the Raspberry Pi Pico have a 5V and 3V3 power out pin.

But when I need more power I use an USB breadboard connector to power the project.


An example is this circuit where two TM1637 7 segment displays are connected to a Raspberry Pi Pico. The Raspberry pi pico is powered through it's USB port and on the left-top side you can see a breadboard USB connector attached to a USB power plug.

Nothing wrong with this but I always seem to run out of breadboard USB connectors.

3D printer to the rescue

Then I found this on the web:
https://www.instructables.com/Minimalist-USB-Connector-No-Special-Hardware-Requi/


This is a 3D printed USB connector. The photo shows the assembled version.
But does it work ????


Works like a charm !!!
As you can see the USB connector is plugged into a powerbank and the multimeter shows that a nice 5V is supplied.

The STL files

The connector consists of 2 parts.

You can find the STL files in the original story which you can find here:
https://www.instructables.com/Minimalist-USB-Connector-No-Special-Hardware-Requi/


The first part is the bottom in which you need to insert the wires. The second part is the top which you should glue and press on to the bottom part when the wires are placed. The top part has ridges that help keep the wires in place.


This is how the files look in my slicer. I use Cura.


Set the quality at 0.2mm and supports on. As these are small parts you could set adhesion also on.

Assembling

I used solid copper wire with a diameter of 0.5mm. That worked very well.

I took a slightly different approach to assembling as what the original developer described.

First I stripped the wires.


Then I pulled the stripped part through the holes.

Then I glued the lid on.
The last step was to cut off the excess wire.

The blue wire at the top is GND.
The red wire at the bottom is VCC (5V).
Please test before you actually put it to use to make sure the wires are not twisted. If you mix the wires up you might/will blow up your circuit so test, test, test !!!


The wires are thick enough to fit direct into a breadboard.

You can make the wires any length you want. Short to connect to a powerbank and fit on your desk. Or make them long to connect to a wall outlet with an USB power plug.

I have printed several of these. They are ready to use in my drawer. A really great design.

Til next time
Have fun

Luc Volders

Friday, September 13, 2024

Testing an obstacle avoidance sensor

For an index to all my stories click this text

I was playing around with an obstacle avoiding sensor and want to share my experiences with you.

What is it.

An obstacle avoidance sensor is mostly used in robotics.

The sensor has an infrared led. This led sends out lightin the infrared spectrum which we can not see. the light normally shines streight on.

Next to the infrared led there is a photodiode. That photodiode detects infrared licht.

When the sensor approaches an obstacle the infrared light is reflected back and detected by the photodiode.

Like said, this is mostly used in robotics. The sensor is mounted on a robot and when the robot comes close to a wall or any other obstacle the photodiode sends a signal to the robots controller to alter direction.

The sensor

This is how the sensor looks in real life. Let's have a look at the different parts of it.

On the left you can see the photodiode at the top and the IR led beneath it. They are next to eachother so the there is a maximum chance of detecting any reflection.

In the middle there is a screw with witch you can adjust sensitivity. That means by turning the screw you can adjust the maximum distance at what the reflection is detected.

Next to the header pins there are two leds. The top led is the power led and that is always on whenever the sensor has power. The led at the bottom is off and goes on when an obstacle is detected.

A test setup

To test the sensor I build a simple setup on a breadboard. I connected the sensor to a Raspberry Pi Pico. Here is what the breadboard looks.


The led (I used a blue one) is connected with a current limiting resistor to GND and to GPIO15.

Pico's GND (pin38) is connected to the sensor's GND. and Pico's 5V (pin 40) is connected to VCC. The sensors output (OUT) is connected to GPIO16.

Test program in MicroPython

To test the sensor I wrote a simple program in MicroPython.

import time
from machine import Pin
obstac = Pin(16, Pin.IN)
led = Pin(15, Pin.OUT)
while True:
 print(obstac.value())
 led.value(not obstac.value())
 #led.value(0)
 time.sleep(.2)

In the loop the program constant tests the out pin of the sensor. When that pin's output changes from 1 to 0 (obstacle detected) the led on GPIO15 goes on.

Copy this program, paste it in Thonny and save it as main.py on your Pico. It will work on the Pico, Pico W and Pico2.
Saving it as main.py makes the program run immediately when the Pico is powered up so you can do some tests with a powerbank, phone charger or batteries.

If you want to learn about MicroPython on the Raspberry Pi Pico or Pico W please consider buying one of my books that are listed at the bottom of this page.

First test.

This should immediately work. Just hold your hand above the sensor and move it towards the sensor. At a certain moment the led will go on both on the sensor as well as the blue led.

Now you can adjust the screw in such a way that the leds will go on at your desired distance.

Distance

According to some specifications I found you can adjust the screw so the distance at which the led will go on can be set from 2 to 20 cm.

Just be aware that there are environmental issues that might influence the detection distance. Here are some things you might like to take into consideration.
- Temperature may affect the distance
- TL light might affect the distance
- Sun light might affect the distance
- Direct light shining on the photodiode might affect the distance

The only thing I want to say is that you should adjust the sensivity screw in your real-life setup.

Some tests

Here are the results of some tests I performed.


All leds are OFF because there is no obstacle in front of the sensor.


A shining transparant box was put in front of the sensor and at a distance of 8 cm the obstacle was detected.


A black piece of paper was put in front of the sensor and at 6cm it was still not detected.


The black paper was detected at 2.5 cm.
This means that the black paper absorbed (did not reflect) a lot of infrared light so it was not detected until it was at a short distance.


A white piece of printer paper was detected at 8 cm distance. The white color reflects the infrared light more so the paper was earlier detected.


A black shining object was detected at 4cm. This means that the black color absorbed some infrared light but the shing surface reflected also some infrared light.


A book (yes my book about the Pico) with a shining green cover reflected the infrared light at a larger distance so it was already detected at about 8.5cm

Water ???

Solid obstacles: OK
But how about fluids.

If you want to reproduce this test yourself just make sure the electronics don't get wet. Water and electronics don't mix and you might damage your sensor or pico beyond repair.


I filled a white bowl with a small layer of water and help the breadboard above it.
The led stayed off: no obstacle detected.


I used a bottle of water to gradually fill the bowl and yes !!!
At a certain moment the led went on. So water reflects the infrared light.


Concluding

First let me state that obstacles are detected very well.
In the demo program you can lower the delay and that will not affect the working of the sensor. So in real life you should use an interrupt for testing for an obstacle which is the fasted method.

The obstacle avoidance sensor detects obstacles but does not give any indication at what distance the obstacle is 'seen'. The difficulty lies in different materials reflecting the infrared light more or less.
If you need to measure distance then use an HC-SR04 ultrasonic sensor.

This means that you should adjsut the sensivity screw so that the obstacle is detected at a larger distance when you are working with a fast moving object like a remote controlled car. That is because you will need time to shut the motor down. But you also need to take the obstacles material in count as black obstacles are seen later.

I was specially impressed when I realised that the sensor also detected water as an obstacle.
I did not try but wonder if a black bowl would make a difference.

And remeber: you can always use this sensor inverted. Meaning that an alarm is given when an obstacle is removed like the lid of a box is taken off.

Till next time
Have fun

Luc Volders

Friday, September 9, 2022

An easy gesture controller

For an index to all my stories click this text

As you might know by now I wrote, up to now, two books. A book about the ESP32 and a book about the Raspberry Pi Pico. You can find links to these books at the bottom of this page.

In these books I described a tilt sensor called the SW-520D. Lets first look at how it functions inside.



As you can see the way this sensor works is fairly straightforward. On the inside on one side of the sesor there are 2 contacts. And there are 2 metal balls inside. When the sensor is in the upright position the balls shorten the contacts. At an angle the balls still shorten the contacts. When horizontally the balls might shorten the contacts or the contacts are open. And when the sensor is at a down angle there certainly will be no contacts shortened.

You can use this sensor as a switch. You could use it for example as a means to test wether a box is upright or upside down.

Then I had an idea. How about using this sensor to control all kinds of appliences and even as a remote controller for a car. To achieve this you'll need multiple SW-520D's arranged in a particular way. I'll show you the fundamental setup here:





I'll bet you get the idea. Put this on a breadboard and lift the breadboard at an angle downwards and the top sensor will make contact. Lift the breadboard upwards and the bottom sensor will make contact etc etc etc.

So let's put this on a breadboard and attach some leds so the sensors to check wether this works.




The above breadboard setup shows you how to attach all items. The only thing you need to supply externally is power. I use a breadboard connector for a USB power supply or powerbank but you could attach batteries.
Just make sure you put the SW520's in the right way on the breadboard. Mind where the sensor makes the contacts and put the it the opposite way on the opposite sites.




Here is an example on how this looks in real life.

[フレーム]


And here a short movie that demonstrates how this functions. As I am filming and controlling the setup at the same time it is not the best demo but it gives you a good hint on how this works in real life.

When I build this I immediately had some ideas and I will work them out and show them in future stories. In the mean time I will give you a real example here.

Gesture controlled MP3 player.

Remember the MP3 player I described in this article:
https://lucstechblog.blogspot.com/2019/05/mp3-player-stand-alone.html

Well what I did is to replace the buttons with two SW520D tilt sensors.




Re-read the above mentioned story about this MP3 player and adjust the breadboard like this. Now you can control jumping to the next or previous number on the SD card by a quick forward or backwards nod. Keeping the board in an upward or downward angle will set the volume louder or softer.

The setup with 4 sensors is ideal for building some gesture controlled projects. And I will be devellopping them for future stories. So keep on coming back.

Till next time
Have fun

Luc Volders

Friday, May 6, 2022

Interrupts: WTF happened

For an index to all my stories click this text.

Some of you pointed out that there was a problem with my code in the "More buttons on fewer pins" story. Now I must admid that I wrote that story some time ago, published it and forgot about it.
When some readers however mailed me that there was a problem with the software I had to dive into this again. And indeed WTF happened.

Well what happened was that a new version of the Arduino software had some alterations in the interrupt routine. That made the ESP series (ESP8266 and ESP32) microcontrollers run berserk.

What's behind it.

Sometimes programs are loaded from flash memory when run. That works fine for a lot of programs but poses a problem when fast processing is involved.
The Arduino IDE therefore changed the way it handles interrupts. It wants the interrupt handling routine to run in RAM so it is always available when needed, and needs not to get loaded first during execution of a program.

Next to that it is recommended that no delay() command is used in the interrupt routine. As a matter of fact that makes sense. Interrupts generally need to be handled as fast as possible because it may happen that when the interrupt routine is being handled at the same time a new interrupt is initiated.

However in my program that handles a button press speed is not the issue. The interrupt routine is processed a lot faster then you would press another button. But my endeavours in my little corner of the universe is of course of no concern to the developers of the Arduino IDE.

It made however an impact on some of my programs and of course the chapter on interrupts in my book ESP32 Simplified. You can find details on my book here: http://lucstechblog.blogspot.com/2020/06/esp32-simplified-my-book-in-english-now.html

The solution

Luckily the alterations to get things working again are small.

attachInterrupt(digitalPinToInterrupt(D5), buttonpress, FALLING);


In the setup() routine the interrupts are initiated with this line. And that stays the same. The interrupt is attached to pin D5 and when that button is pressed it calls the "buttonpress" routine.

void buttonpress()
{
 // button 1 ==> 011
 if (digitalRead(D5)== LOW && digitalRead(D6)== HIGH && digitalRead(D7)== HIGH)
 {
 strip.setPixelColor(0, 0,255,0);
 strip.setPixelColor(1, 0,0,0);
 strip.setPixelColor(2, 0,0,0);
 strip.setPixelColor(3, 0,0,0);
 strip.setPixelColor(4, 0,0,0);
 strip.setPixelColor(5, 0,0,0);
 strip.setPixelColor(6, 0,0,0);
 strip.show();
 delay(500);
 }


This is part of the "buttonpress" interrupt routine. This is where we need to make the changes. First we need to alter void buttonpress() in ICACHE_RAM_ATTR void buttonpress() So a command is put in front of void buttonpress(). That command is ICACHE_RAM_ATTR and that makes sure that this part of the program is loaded into RAM before the program starts.

Next the delay(500) line must be left out.

So the new first part of the program is:

ICACHE_RAM_ATTR void buttonpress()
{
 // button 1 ==> 011
 if (digitalRead(D5)== LOW && digitalRead(D6)== HIGH && digitalRead(D7)== HIGH)
 {
 strip.setPixelColor(0, 0,255,0);
 strip.setPixelColor(1, 0,0,0);
 strip.setPixelColor(2, 0,0,0);
 strip.setPixelColor(3, 0,0,0);
 strip.setPixelColor(4, 0,0,0);
 strip.setPixelColor(5, 0,0,0);
 strip.setPixelColor(6, 0,0,0);
 strip.show();
 }


Famous last words.

So to get your programs that use an interrupt routine working again put ICACHE_RAM_ATTR in front of the line that defines the start of the routine and remove all delay() statements from your interrupt routines.

PHEW !!!
Easier as I thought.

Till next time.

Luc Volders

Friday, April 15, 2022

Simulate your controllers with WOKWI

For an index to all my stories click this text.

There is always something new to play with just around the corner.
And for one reason or another I frequently stumble on something called WOKWI. So I decided to have a look on what's it all about.

Short cut
WOKWI is a simulator. It simulates several Arduino and Raspberry controlers. In the right part of the screen you draw your circuit by placing the micro-controller and adding sensors and actuators. Then connect all items with wires just like you would do for example on a breadboard. At the left part of the screen you type your code. When everything is done you press the run button and your circuit runs on the screen just like it would do in a real setup.

So let's have a look on how it functions.

First WOKWI is a free service. You can find it here: https://wokwi.com/

The opening page offers you to login. The good part is that you do not need to. You do not have to login to use the service. The draw-back is that you can not save your projects if not logged in. You can build them, test them but just can not save them. So the choice is yours. I decided to create a login.



Start with choosing the controller you want to simulate. The opening screen shows that you can choose from:
- Arduino Uno
- Arduino Mega
- ESP32
- Arduino Nano
- Raspberry Pi Pico
- MicroPython on ESP32
- Franzininho Project (never heard of it)
- MicroPython on Pi Pico



Clicking on more options reveal some more.

So next to programming the ESP32 with C++ (Arduino) you can also try programming the ESP32 with MicroPython. And for the Raspberry Pi Pico there is C++, MicroPython and CircuitPython. And there are several Arduino's to experiment with. All in all a lot to dive into.

As you might (no should !!) know I have written a book on the Raspberry Pi Pico which focussed on programming the Pico with Python for beginners.

You can find more information here: http://lucstechblog.blogspot.com/2021/08/raspberry-pi-pico-simplified-now.html

And as you can see WOKWI offers a simulation for the Raspberry Pi Pico with Python. So I just had to try that !! I tried two examples from my book.



At the main page on the top right side there is a drop down menu. Choosing my projects gives a graphical list of all your projects. That is if you made some previously ;)



The first example is a simple setup with a button and a led. The led turns on when the button is pressed.And it worked direct. Pressing the start-simulation button showed a range of 1's when the simulation started and that changed into 0's when the blue button was pressed.

Please remember that WOKWI is a simulator, so the code on the right side of the screen has to be written by yourself. Like said, this example was taken from my book.

You can try this simulation yourself with this link:

https://wokwi.com/projects/328570227913654868




The second simulation is also from my book and that uses a joystick to alter the position of the servo. And as you can see that worked also as it should.

The servo's arm indeed moved according to the position of the joystick.

You can try this simulation using this link:

https://wokwi.com/projects/328572656023503444



When the simulation is not running you can add sensors. You can choose them by clicking on the button in the middle on top of the simulation screen. At the moment of writing there were about 40 sensors and actuators that you can use.

Wokwi is free to use. But there is a paid membership. Paying members have some privileges. They can choose what the next sensor/actuator or feature is that will be implemented.

Altering the schematics is easy.



If the above picture is not to your liking you can click on a component.



When the component (here the Pico) is selected simply press the letter R on your keyboard and it will rotate. The wires will stay connected to their pins but it does not look fancy.



So you have to alter the wiring manually. Which I have done here.



At the right side of your screen is the editor for the program. There is also a tab called diagram. Clicking that tab shows the JSON code for the components of your schematic.



This detail shows the JSON code for the connection of the LED to the Pico.



As you can see by manually changing the colors in the JSON code you can alter the colors of the wires in your schematic. Originally the wires were black and green and I changed them into black and blue.





This is the JSON code for the led itself. WOKWI chooses a red led standard as the led component. By altering the line attrs (attributes) in "attrs": {"color": "green"} the led will change from a red led to a green one.

There is a lot more to be discovered and please do so, as it is fun to play with.

Any Flaws ?

Well while playing with the first example (the led and the butrton) I noticed that when the simulation starts the led is ON just like if the button is pressed while it is not. After once pressing the button everything functions as normal.

This is a small flaw I noticed in my brief tests with WOKWI. At this moment I am not sure if there are more flaws.

Is it usefull ???

Well if you do not own one of the supported microcontrollers Wokwi offers a fun way to explore the possibilities. You can learn programming microcontrollers with MicroPython or C++ (arduino language) without actually owning one. Another option is when you want kids to learn working with microcontrollers without having to fear that something breaks. And you can use Wokwi to test some setups before actually building a prototype on a breadboard.

And: yes it is fun to play with.

Till next time
have fun

Luc Volders

Friday, April 8, 2022

Visible indication for the: more buttons on fewer pins

For an index to all my stories click this text.
In a previous story I showed how to attach many buttons on just a few IO pins. I did this by using diodes to binary decode the buttons. Sounds complicated but it really isn't and it is a great way to have more buttons, switches, door contacts, pir sensors etc without sacrificing too many IO pins. You can re-read that story here: http://lucstechblog.blogspot.com/2019/07/more-buttons-on-fewer-pins.html

The setup was just an example for the tutorial. And in real life pushing one of the buttons would evoke some action. However, how about immediate feedback. Then I had this idea.

Let us look at some basic electronics.



On the left you see the symbol for a diode and on the right side the symbol for a led. That shows that a led is basically a diode that transmits light. Duh..... Hence the name Led: Light Emitting Diode.

So what if I would exchange some of the diodes in my project by a leds. That would show which button was pressed, no matter what actions would follow you would get an instant feedback,



Here you can see that the strip at the right side of the diode points to where the - side is. This is the side to which the buttons are connected. When replacing a diode by a led test with a battery which side of the led is the + and which is the - side. Then replace the diode by a led using the same polarity.

At the buttons where just 1 diode is attached replace that diode by a led. At the buttons where multiple diodes are attached hust replace 1 of the diodes by a led.

That's all.

What leds to use.

Not all led's can be used as for some the forward voltage is to high. The dimmed red and green ones worked for me as did the clear red ones. Just experiment and see what works best in your setup.



Here you can see my setup with 7 buttons attached to just 3 IO pins of a Wemos D1. In this setup I replaced 3 diodes (as a test) with clear red leds.



And here you can see what happened when I pushed the first button. From the string of Neopixels only the first one lightened up just as it should but the led attached to the button also lightened up.

There you go. An immediate feedback when you press a button.

Till next time
have fun

Luc Volders





Friday, September 4, 2020

Arduino and ESP8266 interrupts

For an index to all my stories click this text

Using interrupts can be very handy when designing a project and yet up until now I have almost never used them in Arduino language. My vibration alarm used an interrupt to send an alarm message. That program was written in ESP-Basic, and not in Arduino C++ code.

As I am moving more and more towards to the Arduino IDE (to keep my programs compatible with the ESP32) I wanted to use the interrupts in my new programs. However that turned out to be a bit more complicated as I thought.

Interrupt

An interrupt on the ESP8266, ESP32 or Arduino (any version) is about the same as an interrupt in real life. You put the ketlle on, start reading a book and then the kettle whistles. That is an interrupt. Getting the kettle from the stove is called an interrupt service routine (ISR).

The complication emerges when you are busy getting the kettle from the stove when the cat starts to meow telling she wants to go out. Now what to do. Opening the door leaves the kettle whistling which is annoying. Ignoring the cat is an option. It depends on where you put your priorities.

The solution is to keep the interrupt service routine as short as possible so you will not get into problems when a second interrupt occurs. Meaning you'll take the ketle from the stove as quick as possible.

Or.... You could also ignore the cat till your done with the kettle. That is exactly what I am going to do in my programs.

Test setup



As a demo setup I'll use the Wemos D1 mini with a simple push button attachted to GPIO pin 4 (D2). Do not forget the pull-up resistor to make sure D3 is always HIGH until you push the button.

The test program



int Button = 4; // D2
int intproc = 0;
void setup() 
{
 Serial.begin(9600);
 delay(50);
 Serial.println("started");
 pinMode(Button, INPUT);
 attachInterrupt(digitalPinToInterrupt(Button), ButtonPressed, FALLING);
}
void loop() 
{
 if (intproc == 1)
 {
 Serial.println("The button is Pressed");
 delay (5000);
 intproc = 0;
 attachInterrupt(digitalPinToInterrupt(Button), ButtonPressed, FALLING);
 }
}
void ButtonPressed() 
{
 detachInterrupt(Button);
 intproc = 1;
}


Let us see how this works.

The program starts with attaching the button to IO port 4 which is D2 on the Wemos D1 Mini board. Then a variable intproc is declared and set at value 0.

In the setup first the Serial port is initialised and the word "started" is print on the Serial Monitor. The pin where the button is attached to is declared as an input which is obvious. And then the interrupt is started.

attachInterrupt(digitalPinToInterrupt(Button), ButtonPressed, FALLING);

This line attaches the interrupt to the Button pin. When an interrupt is detected the program jumps to the routine ButtonPressed. And lastly the interrupt is only activated when the pin goes from VCC to GND which is called FALLING.

So what happens when the button is pressed.
The program jumps to the ButtonPressde routine.

detachInterrupt(Button);

This command makes sure that the interrupt is disconnected from the Button IO pin. So when another interrupt occurs nothing will happen, as the interrupt is disabled. The variable intproc is set to 1.

The program now continues with the loop as if nothing has happened. In the loop intproc is tested. If the value is 1 that means that an interrupt has occured. The Serial Monitor notifies us by printing: The button is pressed. Then there is a delay of 5 seconds an after that intproc is set to 0 again and the interrupt is reactivated.

If an interrupt is detected then that interrupt is immediately disabled. So if another interrupt occurs (AKA you press the button again) nothing happens. The program does what it needs to do (wait 5 seconds) and then re-activates the interrupt.
If you press the button and keep it pressed the interrupt will be fired only once as it is only activated on a FALLING signal (from VCC to GND). If you press the button too soon after eachother, being within the 5 seconds delay, nothing will happen either.

There must be a delay for debouncing the button press. However 5 seconds is far too much. One second would be enough for normal purposes. After the delay let your program do whatever it needs to do and when finished you can attach the interrupt again.

I hope this makes things clear. At least it did for me.

Now let's use this in some neat projects.
That is for another story so........

Till next time
have fun

Luc Volders

Friday, March 27, 2020

Steady hand game

For an index to all my stories click this text


In these days of the Corona crisis simple games can help to keep your kids (and yourself) occupied. Therefore I build one. I guess everybode knows this game. There is a track made of wire and there is a loop wich must maneuvered along the track without touching it.





Here is the basic idea. This is a picture from Wikipedia



You can build this with a few electronic parts. You can even build this with just a led and a battery. And you can build it with a ESP8266. Using the latter you can ad leds, 7 segment displays etc. to fancy it up.




Above are a few samples of commercially available versions. Here is my version: 3 strike out !!

I build this with an ESP8266. It can easily be altered for using an Arduino or one of its family members. By exchanging the leds for neopixels and altering the program accordingly you could even use an Attiny85 to make this project.

Breadboard.



The setup is simple. 3 leds are attached to D7, D6 and D5. A button is attached to D0. The track wire is connected to GND and the loop wire is connected to D1. If you do have a Piezo Buzzer attach it to D2.

The program

Nothing special in the program. Each time the wires touch a led is lit, and the buzzer sounds. If you touch the wire more as three times your done and nothing further happens till you push the button and the game is reset for the next attempt or contestant.



const int BuzzerPin = 4; 
const int ContactPin = 5;
const int ButtonPin = 16;
const int ledpin1 = 13;
const int ledpin2 = 12;
const int ledpin3 = 14;
int count;
void setup() 
{
 pinMode(ContactPin,INPUT_PULLUP);
 analogWrite(BuzzerPin, 0);
 pinMode(ledpin1, OUTPUT);
 pinMode(ledpin2, OUTPUT);
 pinMode(ledpin3, OUTPUT);
 digitalWrite(ledpin1, LOW);
 digitalWrite(ledpin2, LOW);
 digitalWrite(ledpin3, LOW);
 count = 0;
}
void loop() 
 {
 if(digitalRead(ContactPin)==0)
 {
 analogWrite(BuzzerPin, 200);
 delay(400);
 analogWrite(BuzzerPin, 0);
 if (count <3)
 {
 count ++;
 }
 }
 switch (count) 
 {
 case 1:
 digitalWrite(ledpin1, HIGH);
 break;
 case 2:
 digitalWrite(ledpin2, HIGH);
 break;
 case 3: 
 digitalWrite(ledpin3, HIGH);
 break;
 }
 if ((digitalRead(ButtonPin)== LOW) && (count == 3))
 {
 digitalWrite(ledpin1, LOW);
 digitalWrite(ledpin2, LOW);
 digitalWrite(ledpin3, LOW);
 count = 0;
 analogWrite(BuzzerPin, 0);
 delay (1000);
 }
 }

If you do not own a buzzer you can easily leave that part out. The program can easily be modified to use a display instead of leds etc.

In real life.

I just used a solid electrical wire for the track and a piece of the same wire for the loop.



Above is my prototype on a breadboard. The track is a wire across the breadboard. The loop is on the left side at the bottom. A coathanger is the best material for the loop and track. Put it on a wooden shelf for sturdiness and experiment with different shapes.

Have fun

Luc Volders
Subscribe to: Comments (Atom)

AltStyle によって変換されたページ (->オリジナル) /