Maker Pro
Maker Pro

How to communicate between two devices?

AndreeU17

Apr 23, 2014
42
Joined
Apr 23, 2014
Messages
42
Exactly correct. These would be simplified versions of what I had shown you earlier, but would be more than capable of sending the trigger to turn your LED's to full brightness. Using the more complex items would allow you to send additional commands... ie, if you wanted turn signals to cause a reaction in the helmet


Have you seen the size of the AVR microcontrollers I had shared? The 8-pin AVRs would have more than enough horsepower to handle many simple commands and to manage more than one set of lights. The sizes shared are no bigger than a 555 timer in the same package, which you would most likely require anyway along with a couple other components. Ideally, when your LED's are dim, you will want to be driving them with PWM which will require some sort of logic whether it is built into a microcontroller, or built out of other components.
Remember though that the same parts can usually be purchased in surface mount packages which can reduce the size considerably. The advantage of a microcontroller is freedom ;) At anytime you can change how the circuit functions by changing the program. You want the LEDs to flash twice before staying constantly lit? no problem! You want the to turn on hard, then fade back to the original brightness? again, no problem! You can even program in multiple modes, and choose which one you want to use when you turn your helmet on ;)
As far as the LED strips are concerned... this is the consideration that needs to be made: power consumption. If you buy a pre-made light strip, you may be stuck with a strip that wastes power through current limiting resistors which will reduce your battery life considerably. Building your own may not be the easiest... but once you have some ideas on hoe bright and how many, we can work out some numbers to determine what kind of battery is required, or if we will need to modify the light strip to comply with the requirements.
Have you put any thought into how long you want the helmet to remain powered in between charges? (I would recommend rechargeable Li batteries as they are lighter, and can be built into the case you will use to hold your components... using AAs or other disposable/rechargeables will greatly affect weight and size due to their shape, and the metal casing used.)


Before you buy any equipment to test/troubleshoot or build with, it would be a great idea to plan out the circuits first so you know what parts you will be using.
Remember this is the planning stage, so you are more than welcome to plan your helmet circuit with and without a microcontroller to see what parts will be required in the end product.

This is something I would have no problem working on with you, as like I have said, I have been thinking of the same idea for my jacket. ( I have also thought of using EL Sheet or EL Wire... but they degrade pretty quickly in the sun. My thought process was more for night riding anyway though, so overall brightness was not a concern.)

I'm looking for an avr chip for my custom microcontroller, I found a bunch on spark fun however some had the same specs but just different type of pins, how do I know which one benefits my needs? I saw this one and I though I'd buy it:

https://www.sparkfun.com/products/9061

Not super big and decent, however I'm worried the 32k of flash isn't enough!!! Tell me or explain to me if possible, what I should search for when choosing the microprocessor for a microcontroller ? (I'm prefer AVR) and what type of pin should I search for? Or does pin not matter? I need something that needs to be able to be reprogrammable !!!
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
32k flash is more than enough!
If you're using a sender/receiver pair that was recommended earlier, your program will be quite simple:
Initialize the AVR and set pin states.
Begin Loop.
Test Pin from receiver.
If high, set LED output pin to high.
If low, set LED output pin to PWM at 50% duty cycle.
pause 100ms
End Loop.

This is not legitimate code of course ;) but you get the idea.
That could very very easily fit and operate just fine on
https://www.sparkfun.com/products/9378

Of course, if you are using a transceiver, or a transmitter/receiver pair that deal with serial data your program will have a couple additional commands to see if the appropriate command was received. This will let you implement more features later on but is not required for your current application.

Because of the simplicity of the application that will be written to the AVR, I am pretty certain all you really need to worry about is finding an AVR with the required amounts of pins.
Remember that 1 pin can control a group of LEDs. You can split your LEDs into any number of groups to suit your needs.
Typically, 1-2 pins will be required for serial communications.
1 pin for power, and another for ground.
Additional pins for extra buttons or groups.
 

AndreeU17

Apr 23, 2014
42
Joined
Apr 23, 2014
Messages
42
32k flash is more than enough!
If you're using a sender/receiver pair that was recommended earlier, your program will be quite simple:
Initialize the AVR and set pin states.
Begin Loop.
Test Pin from receiver.
If high, set LED output pin to high.
If low, set LED output pin to PWM at 50% duty cycle.
pause 100ms
End Loop.

This is not legitimate code of course ;) but you get the idea.
That could very very easily fit and operate just fine on
https://www.sparkfun.com/products/9378

Of course, if you are using a transceiver, or a transmitter/receiver pair that deal with serial data your program will have a couple additional commands to see if the appropriate command was received. This will let you implement more features later on but is not required for your current application.

Because of the simplicity of the application that will be written to the AVR, I am pretty certain all you really need to worry about is finding an AVR with the required amounts of pins.
Remember that 1 pin can control a group of LEDs. You can split your LEDs into any number of groups to suit your needs.
Typically, 1-2 pins will be required for serial communications.
1 pin for power, and another for ground.
Additional pins for extra buttons or groups.

The coding is the least of my worries since i have a more than basic knowledge in C/C++ and other programming languages. Now, what if i decided down the road to later upgrade the circuit and add other features? Would the tiny one be more than sufficient to supply more better features down the road? Also as for pins, i understand each has a respective function or command that must be followed, but would it be fine if i choose an AVR that has more pins than necessary in case later i'd like to add a button or something?
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
The coding is the least of my worries since i have a more than basic knowledge in C/C++ and other programming languages. Now, what if i decided down the road to later upgrade the circuit and add other features? Would the tiny one be more than sufficient to supply more better features down the road? Also as for pins, i understand each has a respective function or command that must be followed, but would it be fine if i choose an AVR that has more pins than necessary in case later i'd like to add a button or something?
The vast majority of pins are General Purpose and can be configured as Inputs, or Outputs.
Typically the 'special pins' like Analogue to Digital converters, PWM, and certain communication capable pins are the pins that are limited. (These functions can usually be implemented through software methods though... although not always easily)
You are more than free to future-proof your creation by using such hardware. That said, there is only so much you can alter a circuit once it is built merely by programming and additions. Planning for 'possible' upgrades will assist in designing your initial circuit and choosing your MCU.

As a reference for what the Tiny can do...
I have scabbed together in a very sloppy program 8 different flashing patterns for 4 outputs to drive LEDs.
Each pattern is stored in a pair of variables as an array of 10 nibbles each.
As I rotate a connected potentiometer, the built-in ADC pulls the value which is used to determine which set of variables is used.
The tiny will then cycle in an alternating fashion though the pair of selected arrays.

I could not get a 9th pattern to work with this program method, but could have easily if I had stored my patterns in PROGMEM instead of using variables.
This is not a completed program, but merely something I used as a proof-of-concept to a very eager friend of mine.
The selected clock rate is slow, and the outputs change every 50ms.

The tiny is capable of a lot more than my sloppy implementation, but would still struggle if you wanted multiple parallel features or tasks to be handled at a time.

*So I have no easy answer, but the AVRs are cheap ;)
Buy what you feel comfortable working with. Only you know what your possible additional features could be. Your imagination and physics are your limits
 

AndreeU17

Apr 23, 2014
42
Joined
Apr 23, 2014
Messages
42
The vast majority of pins are General Purpose and can be configured as Inputs, or Outputs.
Typically the 'special pins' like Analogue to Digital converters, PWM, and certain communication capable pins are the pins that are limited. (These functions can usually be implemented through software methods though... although not always easily)
You are more than free to future-proof your creation by using such hardware. That said, there is only so much you can alter a circuit once it is built merely by programming and additions. Planning for 'possible' upgrades will assist in designing your initial circuit and choosing your MCU.

As a reference for what the Tiny can do...
I have scabbed together in a very sloppy program 8 different flashing patterns for 4 outputs to drive LEDs.
Each pattern is stored in a pair of variables as an array of 10 nibbles each.
As I rotate a connected potentiometer, the built-in ADC pulls the value which is used to determine which set of variables is used.
The tiny will then cycle in an alternating fashion though the pair of selected arrays.

I could not get a 9th pattern to work with this program method, but could have easily if I had stored my patterns in PROGMEM instead of using variables.
This is not a completed program, but merely something I used as a proof-of-concept to a very eager friend of mine.
The selected clock rate is slow, and the outputs change every 50ms.

The tiny is capable of a lot more than my sloppy implementation, but would still struggle if you wanted multiple parallel features or tasks to be handled at a time.

*So I have no easy answer, but the AVRs are cheap ;)
Buy what you feel comfortable working with. Only you know what your possible additional features could be. Your imagination and physics are your limits


Haha the truth I don't plan on upgrading it, I plan on maybe adding more LED Strips or adding different types of color schemes! But adding other components is a rarity for now!!!
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
Haha the truth I don't plan on upgrading it, I plan on maybe adding more LED Strips or adding different types of color schemes! But adding other components is a rarity for now!!!
Well.. It's your call then on what you want to use ;) You can always use a larger AVR and just not use the pins.
If you plan to use a different color scheme, it sounds like the basic operation of the circuit will stay the same. Perhaps look for an AVR that has more hardware PWM capable pins. (One for each group of lights you want.)
 

AndreeU17

Apr 23, 2014
42
Joined
Apr 23, 2014
Messages
42
Well.. It's your call then on what you want to use ;) You can always use a larger AVR and just not use the pins.
If you plan to use a different color scheme, it sounds like the basic operation of the circuit will stay the same. Perhaps look for an AVR that has more hardware PWM capable pins. (One for each group of lights you want.)

Okay now that we have the microprocessor (is it called a microprocessor or microcontroller)? I know resistor and LED is easy and I can figure it out alone, how about transmitting and receiving data! I was reading from SparkFun, about IR communication (infrared communication), would that be a beneficial way of communicating from bike to helmet? What other type of communication is there that is easy to understand and can only read a radius of about 10 feet max!

I found these two, RF receiver and RF transmitter
https://www.sparkfun.com/products/10532
https://www.sparkfun.com/products/10534
 
Last edited:

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
Okay now that we have the microprocessor (is it called a microprocessor or microcontroller)? I know resistor and LED is easy and I can figure it out alone, how about transmitting and receiving data! I was reading from SparkFun, about IR communication (infrared communication), would that be a beneficial way of communicating from bike to helmet? What other type of communication is there that is easy to understand and can only read a radius of about 10 feet max!

I found these two, RF receiver and RF transmitter
https://www.sparkfun.com/products/10532
https://www.sparkfun.com/products/10534

TBH, I've never looked up the term. I have always referred to them as microcontrollers. I'd have to google for an answer.
Transmitting and receiving data can be done multiple ways. I would avoid IR, as it requires direct line of sight between the receiver on the helmet and bike transmitter and can pick up a fair amount of noise from other IR sources such as the sun and incandescent lights. That and if you do a shoulder check, your helmet may loose it's connection to the bike... RF is not immune to noise, but I'm sure you'll have a more reliable connection than with IR.
Many of the RF devices are merely pipes that accept serial data in and spit serial data out the other end. You can find example code for a 'transceiver' here : http://playground.arduino.cc/InterfacingWithHardware/Nrf2401
For this product . https://www.sparkfun.com/products/152

You can practice serial communication between devices by directly connecting their serial lines. This is the stage I am at with my Raspberry pi and my Attiny.

If you still want an alternative solution... the only other thing I can think of would be an induction loop, but I would not know where to start to build one. (I have seen a small one in use as a bluetooth pendant that would pair to my motorcycle teachers phone. His hearing aid would then pick up any audio that the pendant received.)
 

davenn

Moderator
Sep 5, 2009
14,254
Joined
Sep 5, 2009
Messages
14,254
Okay now that we have the microprocessor (is it called a microprocessor or microcontroller)?

Generally, a microprocessor refers to the main processor chip inside your computer, tablet, phone etc

micro-controllers move commonly refer to the PIC's, ATMEL's, etc

DAve
 

AndreeU17

Apr 23, 2014
42
Joined
Apr 23, 2014
Messages
42
TBH, I've never looked up the term. I have always referred to them as microcontrollers. I'd have to google for an answer.
Transmitting and receiving data can be done multiple ways. I would avoid IR, as it requires direct line of sight between the receiver on the helmet and bike transmitter and can pick up a fair amount of noise from other IR sources such as the sun and incandescent lights. That and if you do a shoulder check, your helmet may loose it's connection to the bike... RF is not immune to noise, but I'm sure you'll have a more reliable connection than with IR.
Many of the RF devices are merely pipes that accept serial data in and spit serial data out the other end. You can find example code for a 'transceiver' here : http://playground.arduino.cc/InterfacingWithHardware/Nrf2401
For this product . https://www.sparkfun.com/products/152

You can practice serial communication between devices by directly connecting their serial lines. This is the stage I am at with my Raspberry pi and my Attiny.

If you still want an alternative solution... the only other thing I can think of would be an induction loop, but I would not know where to start to build one. (I have seen a small one in use as a bluetooth pendant that would pair to my motorcycle teachers phone. His hearing aid would then pick up any audio that the pendant received.)

Do I need another microcontroller when using RF transmitter/receiver? From the google searches I've been looking etc, I've found that I need 2 microcontroller but that seems to make it bulkier in the helmet, what other forms of communication is there before RF & IR?
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
Do I need another microcontroller when using RF transmitter/receiver? From the google searches I've been looking etc, I've found that I need 2 microcontroller but that seems to make it bulkier in the helmet, what other forms of communication is there before RF & IR?
Well... let's split this up.
Your transmitter has a lot more freedom as far as power requirements and size.
What you absolutely need is a communication method. The method you choose will partially dictate what you need to control it with.

There are simple RF sender receivers that operate on a very simple principle. The sender has a single input, and the receiver has a single output. This allows such simple projects as pushing a button and having a the receiver light up an LED. (But only as long as the button is held, or as long as the signal is received)
IR communication for your project would work in the exact same way, but may suffer more from interference or line-of-sight issues. IR parts are cheap and you can always experiment with it anyway.
These methods will need to be purpose built for your current feature set, as there are typically no 'intelligent' parts in use to dictate or interpret any other signal than on or off.

Some more of the advanced RF modules will do the same as above, but have multiple inputs and outputs. Again, these would typically be used without microcontrollers. The advantage to these modules is that you can add on to your circuit later (if for example, you wanted to integrate turn signal lights).

Both of the above methods will require additional circuitry to properly drive the LED strings you will be using. Like PWM to drive them in the dim state.
Take a look here: http://www.instructables.com/id/Yet-Another-Simple-Pot-controlled-555-PWM-generato/
Please keep in mind that these LED driving methods are not requirements, but are a very very good idea to use. They will help drive the LEDs in a more efficient manner which will directly translate to longer batter life.
Of course, you can always just use a higher rated resister to drive the LEDs in their 'dim' mode normally, then bypass that resistor when you want to turn them up to full brightness. This is not ideal though, as the resistors will dissipate a lot of energy as heat which will drain your battery quicker. As far as 'bulk' is concerned, please note that the 555 timer is the exact same size as an Attiny ;)

Now for a little more advanced types of communications.
Serial communications.
These communication methods will typically require a microcontroller on each end of the communications. So you will need one in the helmet connected to the receiver, and one in the bike connected to the sender. This method will allow the microprocessor to completely control the string, or strings of LEDs that you plan to use. Also, because of the communication method, you have the ability to send more than one type of signal without having to build additional circuitry and adding bulk to the helmet.

If you want more communication methods, there is always hard-wired.
Light, Radio, Wire. Pick your poison.

Edit: I'm sure someone will post a schematic of an IR sender receiver pair that can send multiple commands. What I had in mind with the post was a simple detector ;)
 
Top