I have Started this thread,

As I think we can rebuild the VUM that Alex Sardo did,

We have knowledge here,  I have been working on information recovery  for some time and will start it off .

If you have skills in this area please try and post schematic programming etc .

Section I will start with will be 1 videos, 2 pics, 3 misc data on it.
You may be able to flash and program MSD ignitions in engine component modauls
and that may be what alex did and why is progressed so fast.

It should be NOted that after a lot of research PLX Devices is very close to the same
method, and could be modified ot suport 60% of the work immediately off the shelf in a good start and or frame work.

If you contact old dealers or have old un working model from Alex Sardo Hydroxy corp , please pull them apart and photo graph all part make thousand of pics
of board individual parts and or send to russ please .

NOte

different sensor on you car work different way some use resistance, some use voltage some are draw from OBD2 connection direct from ecu, emu alex had mastered this and made ic in his split the connection fom sensor to Emu and make its reading adjustable so he could trick emu, also he had reading of temp voltage from cells and had it auto adjusting inline with demand ,  very cool, this could be just a interface to a after market ecu emu like wolf  with multi guages from lx or it

could be a base line for system for auto reading and adjusting and providing better gauging of stan system REBIRTH

instead of using  Gas managmenet system
stan and stephen manual adjusting card
and reading which slowed thing a little explaning

when they were at the end of the program  

Have  a good think on this thread.

And look at injector thread and Particulary the
Gas Management unit thread


Dan



Software from VMU

Alex Sardo Work At Hydroxy tech.

This is a salvage and rebuild so we keep the knowledge of
what and how he did the sensor gather and readings.

I will post yo tubes of version 4

like schematics tried e use basic risc contoller.
ardino may do this now?

Daniel

Videos for downloading with downloadhelper.net

7 VMU_Series_2_Released_Oct_3rd_08_

VMU_Series_2_Proportional_PWM_O2

Wide_Range_or_Air_Fuel_Ratio_Sensor

C3K_to_Go_Channel3000_com

CAM_or_Camshaft_Position_Sensor_Testing

Clio_3_RS_197Ch_-_OBDKey_OBDGauge

Demonstration_Of_VMU_Series_2_OBD2_RPM_based_production

Fuel_Injector_Operation

Fuel_Rail_Pressure_Sensor

HHO_51.5_reduction_in_emissions_with_M-Cell_In_

HHO_ALEXIS_HYDROXY_FUEL_CEL

HHO_VMU_Series_2_with_OBD2_Interface

HHO_VMU_Vehicle_Management_Unit_x_Alexis_Hydroxy_Boosters\

Ignition_Coil_Testing

Injector_Circuit_Wiring_Diagram

Knock_Sensor_Operation

Magden_Linux_OBDII_Gauge_Software_-_SEMA_2008

Microchip Graphics Solution for Human Interface Applications

MileageSeekers

OBD-II_Data_Link_Connector_DLC

Open_Circuit_Detection_Wiring_Diagram

PLX_MultiGauges_installed_in_a_supercharged_Honda_S2000.

Pressure_Sensor_Wiring_Diagram

Scanner_OBD-2_Mode-6

Secondary_Air_Injection_System

Setting_up_the_ELM327_OBD-II_USB_interface_with_ScanTool.

SM-AFR_Wideband_O2_Air_Fuel_Controller_Introduction

PS_or_Throttle_Position_Sensor_Adjustment

TPS_or_Throttle_Position_Sensor_Parameter

Tuning_Performance_-_Reprogramming_the_engine_management_

VMU Discussion

VMU_First_Look

Why_use_a_Fuel_Ignition_Controller_Wideband_O2_Map

VSS_or_Vehicle_Speed_sensor

There are some more VMU Videos around,
look through dealers and other video sites as they are not all on you tube,

you you fine new ones please post and download save and report to you tube

there is one VMU speech recognition v4 and others look
specifically for software instructions , how to flash and board and compnent
for re building

Dan
PS I hope you can see it is fairly simple just connect to the LPG guys or people with this in there hands every day and add better senors gauges to our Stan Stephen meyers map and method

Reason for this post is to raise common knowledge  on it and get a rebuild of vmu starter if it is open source I think we will see some development
Save the software I attached it is a rare commodity  

I support the idea that fuel repacement can be done. the way i see it, most of us will have fuel injected vehicles so the 2 ways of achieving the goal would me: a hybrid of petroleum/gasoline and hho or 100% water/hho.

 Because this is going to take some time to achieve, the problem i see is the hybrid mixing of petroleum and hho particularly with fuel injected vehicles because fuel injected vehicles to my understanding so far limit the amount of variation of fuel consumption to the map and sensors that ultimately control the injector pulsewidth.

For a hybrid install on a fuel injected vehicle, petrol / gasoline consumption reduction has to come from : change in driver behaviour pattern, altering injector pulse width, engine timing, increased combustion efficiency, and importantly engine lubrication.

 As i explained elsewhere i went to a diesel oil spark rated in my vehixle because under friction testing the particular brand had the highest film strength(ability to keep 2 surfaces apart) and the powerup additive in the oil further reduces any friction and ultrasonic friction, add it to the fuel for upper cylinder lubrication also makes a difference.!

so what is being aimed for? I want a way to measure the vehicles sensors in real time and log it, add hho and measure, this then will  tell me what the sensors are doing otherwise we are guessing and measuring only by driving and fuel cost is expensive testing. If theres a sensor change then technically the signals to the ecu must be changed. My current project under construction is to use an arduino board to datalog the sensors, the digital pins can interface with a obd2 interface board to interrogate the ecu live time to get some data, the analog pins can be used to measure injector pulsewidths and any other sensor not picked up in the obd2 stream.

parts used:
OBD-II UART - great board because it does all useful protocols: http://www.sparkfun.com/products/9555
TFT lcd screen with microsd card slot http://www.ladyada.net/products/22tftbreakout/
arduino uno board from: http://www.freetronics.com/
power supply regulator to power the uno: http://www.freetronics.com/products/poe-power-regulator-28v
the hard part now is the programming!!!

i think a decision needs to be made. If youre aiming to have a cell set be the fuel supply, will it be a  supplementary supply to existing fuel or a 100% fuel supply OR will the method be to use injectors and bypass the cell idea altogether.?

the OBD2 uart board listed is very useful, whats difficult is to assemble is the programming for the arduino. Ive read the mpgduino and obduino coding sites and they are a challenge to understand, and they have features i dont need, ie calculating fuel usage. fuel usage is simple, fill tank to top of next, drive, fill to top  and write a log, arduino not needed for this.

So what would be useful is a set of coding  forthe arduino to interrotage the stn1110 based board  to retrieve live time data of the sensors, timing angle etc.
cheers

I agree an arduino based ECU or ECU piggy back system is what we want.  I'm sure there are people here that can handle such programming.  I wonder though if a 'flow chart' or something in plain english that describes how the inputs affect outputs (i.e. sensors & injectors), that coders could base their work on first?  An arduino coder may not understand how to control an engine just like an auto mechanic may not understand how to use an arduino.  
I think its possible if teamwork is used.:)

Nate

Quote from firepinto on July 3rd, 2012, 07:44 PM

I agree an arduino based ECU or ECU piggy back system is what we want.  I'm sure there are people here that can handle such programming.  I wonder though if a 'flow chart' or something in plain english that describes how the inputs affect outputs (i.e. sensors & injectors), that coders could base their work on first?  An arduino coder may not understand how to control an engine just like an auto mechanic may not understand how to use an arduino.  
I think its possible if teamwork is used.:)

Nate

I agree Nate, need to marry the two technologies.:cool:

Quote from firepinto on July 3rd, 2012, 07:44 PM

I agree an arduino based ECU or ECU piggy back system is what we want.  I'm sure there are people here that can handle such programming.  I wonder though if a 'flow chart' or something in plain english that describes how the inputs affect outputs (i.e. sensors & injectors), that coders could base their work on first?  An arduino coder may not understand how to control an engine just like an auto mechanic may not understand how to use an arduino.  
I think its possible if teamwork is used.:)

Nate

Hello Nate!!
I think that using megasquit we can solve the problem...check it out and tell me what do you think:
http://www.clubgti.com/showthread.php?136370-How-to-convert-your-Digi-Golf-2-to-MegaSquirt-V3x-P3-28-11-11-The-end-of-an-era!
Scroll down to see the diagram.

Quote from Muxar on July 5th, 2012, 11:03 PM

Quote from firepinto on July 3rd, 2012, 07:44 PM

I agree an arduino based ECU or ECU piggy back system is what we want.  I'm sure there are people here that can handle such programming.  I wonder though if a 'flow chart' or something in plain english that describes how the inputs affect outputs (i.e. sensors & injectors), that coders could base their work on first?  An arduino coder may not understand how to control an engine just like an auto mechanic may not understand how to use an arduino.  
I think its possible if teamwork is used.:)

Nate

Hello Nate!!
I think that using megasquit we can solve the problem...check it out and tell me what do you think:
http://www.clubgti.com/showthread.php?136370-How-to-convert-your-Digi-Golf-2-to-MegaSquirt-V3x-P3-28-11-11-The-end-of-an-era!
Scroll down to see the diagram.

Hey Muxar,
That looks pretty easy to do.  I think we might need a little more control input and output than what it has available though.  Off hand Im thinking of the non-combustable gasse valves.  

Can check  this also check all relative on this

http://www.aliexpress.com/category/200000322/diagnostic-tools.html

Quote from wfchobby on July 3rd, 2012, 02:22 PM

I support the idea that fuel repacement can be done. the way i see it, most of us will have fuel injected vehicles so the 2 ways of achieving the goal would me: a hybrid of petroleum/gasoline and hho or 100% water/hho.

 Because this is going to take some time to achieve, the problem i see is the hybrid mixing of petroleum and hho particularly with fuel injected vehicles because fuel injected vehicles to my understanding so far limit the amount of variation of fuel consumption to the map and sensors that ultimately control the injector pulsewidth.

For a hybrid install on a fuel injected vehicle, petrol / gasoline consumption reduction has to come from : change in driver behaviour pattern, altering injector pulse width, engine timing, increased combustion efficiency, and importantly engine lubrication.

 As i explained elsewhere i went to a diesel oil spark rated in my vehixle because under friction testing the particular brand had the highest film strength(ability to keep 2 surfaces apart) and the powerup additive in the oil further reduces any friction and ultrasonic friction, add it to the fuel for upper cylinder lubrication also makes a difference.!

so what is being aimed for? I want a way to measure the vehicles sensors in real time and log it, add hho and measure, this then will  tell me what the sensors are doing otherwise we are guessing and measuring only by driving and fuel cost is expensive testing. If theres a sensor change then technically the signals to the ecu must be changed. My current project under construction is to use an arduino board to datalog the sensors, the digital pins can interface with a obd2 interface board to interrogate the ecu live time to get some data, the analog pins can be used to measure injector pulsewidths and any other sensor not picked up in the obd2 stream.

parts used:
OBD-II UART - great board because it does all useful protocols: http://www.sparkfun.com/products/9555
TFT lcd screen with microsd card slot http://www.ladyada.net/products/22tftbreakout/
arduino uno board from: http://www.freetronics.com/
power supply regulator to power the uno: http://www.freetronics.com/products/poe-power-regulator-28v
the hard part now is the programming!!!

i think a decision needs to be made. If youre aiming to have a cell set be the fuel supply, will it be a  supplementary supply to existing fuel or a 100% fuel supply OR will the method be to use injectors and bypass the cell idea altogether.?

the OBD2 uart board listed is very useful, whats difficult is to assemble is the programming for the arduino. Ive read the mpgduino and obduino coding sites and they are a challenge to understand, and they have features i dont need, ie calculating fuel usage. fuel usage is simple, fill tank to top of next, drive, fill to top  and write a log, arduino not needed for this.

So what would be useful is a set of coding  forthe arduino to interrotage the stn1110 based board  to retrieve live time data of the sensors, timing angle etc.
cheers

Think it is simple,
get a old fuel injected care and start now do a rotary engine

now a O2 sensor, small micro controller ( Arduino) and short program and you can control the air to fuel ratio.

Fuel injectors
adapt LPG GUys

https://www.youtube.com/watch?v=sAtDB2FCG...h_response

Hi all,

I have been working on an Arduino based Engine Control System for HHO applications, geared for one cylinder 4 stroke engine using a hall sensor at the exhaust valve. It is intented to be more or less a software implementation of what Les Banki has done in hardware some time ago.

I started writing an engine simulator, which works reasonably well, although it is far from perfect, it is great for debugging the ECU:

http://www.tuks.nl/WFCProject/var/Arduino/Engine_Simulator/

And here is the engine control system

http://www.tuks.nl/WFCProject/var/Arduino/Engine_Control_System/

It it also not finished yet,  I still need to make the ignition timing and injector pulse width adjustable by reading some potmeter and I need to connect an LCD,
but the core system appears to work now, so you guys may want to take a look and see whether it it is of any use to you. :)

As it is now, it assumes a hall sensor to be connected to the exhaust valve, which should be connected to the external interrupt pin, which is pin 2.

During starting, all it needs is one complete pulse of the exhaust sensor, provided the value for "exhaustOpenAngle" is entered accurately enough.  Fortunately, this can be measured with the Arduino itself in debug mode....


Regards,

-- Arend --

Quote from lamare on January 3rd, 2014, 01:41 PM

I have been working on an Arduino based Engine Control System for HHO applications, geared for one cylinder 4 stroke engine using a hall sensor at the exhaust valve. It is intented to be more or less a software implementation of what Les Banki has done in hardware some time ago.

Nice work so far lamare.

Having built an engine management system years ago for a Formula SAE race car, I will tell you, this stuff will push your engineering skills to the limit.  Like Les' system, I used mostly hardware CPLDs for all of the timing (24-bit, 10 MHz clocked) functions of the injectors and ignition.  This way all timing values stay static until the micro-controller communicates the new values.  The sole job of the micro-controller is to process all the environmentals, pick-off the current values from the fuel/ignition map and send them to the CPLDs.  If you have the extra processing capability, you can code (as I did) a learn function that will actually run the engine through it's paces and find the optimal fuel/ignition map values based on:

• throttle position

• engine RPM

• engine load/torque

• exhaust temperature

• any other sensors you may have such as air temperature, humidity, air density, etc.

[/list]
For a race car, you must be able to make multiple fuel/ignition map calculations per revolution and override dynamically as the engine is rarely ever in a static configuration.  This is probably way overkill for what your are attempting to do lamare, but is something to think about.  Even in a static configuration, you need to be able to make a least one fully complete set of calculations for a single revolution at max RPM.  If you can't do that, the engine simply won't run correctly.  And what you'll find is the actual time you have is definitely less than two complete revolutions, so make your lookups in priority order so you execute them before the next event comes up.  If you get behind, you need to keep whatever the last value was and just skip that lookup, but don't skip the same lookup more than once.  Having only a single crank trigger position will mean you have no way of knowing any change in RPM for two complete revolutions--this may be fine for a generator, but certainly no good for a racing application.

To get more processing speed from your micro-controller you'll need to store all of your fuel/ignition maps as timer ticks so you don't have to constantly convert from RPM to ticks and back again.  Timer ticks alone will actually be much easier to think about when considering a rotating device and when the next event needs to be processed.

I don't want to spoil your fun with this, because it's a true joy to see it actually work and know you built it yourself.  Something you'll never forget, trust me.  If you need any help along the way though, just holler.

Quote from Matt Watts on January 3rd, 2014, 03:58 PM

Quote from lamare on January 3rd, 2014, 01:41 PM

I have been working on an Arduino based Engine Control System for HHO applications, geared for one cylinder 4 stroke engine using a hall sensor at the exhaust valve. It is intented to be more or less a software implementation of what Les Banki has done in hardware some time ago.

Nice work so far lamare.

Thanks!

So far, my goal is to get a simple 4-stroke engine to run on a Meyer replication WFC as a proof of concept:

http://www.tuks.nl/wiki/index.php/Main/MeyerWFCReplicationProject

For now, I'd like to keep things as simple as possible. For the gas injection, I might start with a simple manual "throttle" (a potentiometer), or perhaps a PID controller to keep the RPM constant. An Arduino is quite limited with respect to processing power.

For more complicated control units, I would consider taking a close look at the Raspberry Pi:

http://en.wikipedia.org/wiki/Raspberry_Pi

That one has 256 MB+ memory, a 700 MHz ARM processor AND a GPU. So, it can handle a lot more complicated processing stuff, although it's standard i/o is quite limited.  There is an expansion board, the Gert board, though:

https://projects.drogon.net/raspberry-pi/gertboard/

Quote

The Gertboard is an add-on GPIO expansion and experimenter board for the Raspberry Pi computer. It comes with a large variety of components, including buttons, LEDs, A/D and D/A converters, a motor controller, and an ATmel ATmegs 328p AVR microcontroller which you can program using the standard Arduino IDE (with some minor modifications)

So, it's actually kind of an Arduino as an expansion for the Raspberrry.

And now there is also the Gertduino board:

http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/gertduino?ICID=piaccssy-gertduino-learn

Quote

GertDuino is an Arduino and Arduino Uno compatible GPIO expansion board for use with the Raspberry Pi by Gert van Loo. GertDuino offers onboard Atmega 328 shield hosting which will execute Atmega 328 code written and compiled on the Raspberry Pi. The onboard Atmega 48 provides RTC, IrDA front-end, and additional computational capability.

So, it appears the two architectures can be married nicely if need be. :D


BTW, I did find an Arduino based ECU system on the net, with source code, too:
http://scottsnowden.co.uk/?cat=34

Okay one more hint:

Cypress PSoC 5LP.  I can guarantee this will give you all the processing power you will ever need.  The main reason is that you can program the hardware as well as the software all in the same device and your motor will thank you.

Programming a high level language like C means that you don´t have exact knowledge about the exact assembler code produced by the compiler for statements and library functions because depending on context they can change. C++ is even worse.

one way to overcome that problem is to implement some subroutine code in assembler mnemonics and you will know quite well the timing used for code completion or you have to analyze the time critical parts of the asm code produced.

another issue is interrupt usage. whenever you have to implement a real time  ICE control as Matt described and you want to implement optimization functions adopting param tables etc. or if you have to immediately react on environmental events you have to use interrupt techniques. that also makes timing calculations difficult.

as an alternative you can use parallax propeller chip which serves 8 idependent processor cores with no need for interrupt timing issues. on the other hand there is little premade code you can use in opposite to wide spread arduino code ...

whatever processor you use you will have to get into detail for any hardware solution and get familiar with it´s specifics to implement an ICE control.

I personally like the PSOC5 implementation because of it´s powerful design and I know that it will expand my current experience into FPLA like coding.

after 2 years of experience with parallax propeller coding this has started to feel like a home run for me. also a very fulfilling experience :-)

Quote from securesupplies on October 2nd, 2012, 02:14 PM

now a O2 sensor, small micro controller ( Arduino) and short program and you can control the air to fuel ratio.

Fuel injectors
adapt LPG GUys

https://www.youtube.com/watch?v=sAtDB2FCG...h_response

According to Les Banki, things are a bit different with HHO compared to hydrocarbon fuels:

http://www.tuks.nl/wiki/index.php/Main/LesBankiProject#IgnitionSystemForSmallEngines

Quote

First, some engine data.

The crank shaft on a 4 stroke engine turns twice (720º) for every ‘work’ cycle. Since most (if not all) small engine designs use a magnet on the fly wheel (which is mounted on the crankshaft) to generate the ignition sparks, 2 sparks are delivered for every work cycle. The second spark (which is delivered during the exhaust stroke) is NOT needed and so it is called “waste spark”. With hydrocarbon fuels it is harmless.

However, with Hydroxy ONLY, this “waste spark” MUST be eliminated.With hydrocarbon fuels, ignition usually takes place around 8º before TDC to allow some atomization of the fuel before the actual ‘explosion’, which occurs approximately 10º after TDC.

If Hydroxy is ignited at ANY point before the piston has reached TDC, the explosion takes place at that INSTANT. (There is NO delay or atomization here since it ‘burns’ about 1000 times faster than hydrocarbon fuels and it could be said that it is not ‘burning’ but exploding!) The force of the explosion instantly tries to push the piston DOWN when it is still trying to come to the top to complete its compression stroke!

[...]

It needs to be pointed out that the ignition system for Hydroxy ONLY (not just a booster) will be very different from ignition systems for hydrocarbon fuels.

It will be significantly simpler.

There will be NO “speed mapping”, NO “load mapping”, NO retard/advance change with engine RPM, NO rich/lean mixture setting, NO cold start setting, NO “knock sensor”, NO fuel/air temperature sensor, NO Oxygen sensor, etc., etc., (“modern” engines are full of all that rubbish!)

There will be NO need for high energy sparks, multiple sparks, etc.

Further, there will be NO such thing as UNBURNED fuel remaining in the cylinders!!

In short; when we get to the larger engines (cars), the first thing we have to do is to rip out the “computer” and install our own system, incorporating electronic injection as well.

For injectors, Les uses the JET 21, which I will also be using for my system:

Quote

The injection solenoid I have (I intend using this brand in production) is a Gas injector type JET 21, made by POLYAUTO in Italy. It is the largest of their range and has an output orifice diameter of just under 6 mm! Its typical working pressure is rated at 70 kPa rel. , maximum is 120 kPa rel.

I got two of these here: http://www.poliauto.net/jet_injector.html


As for some indication regarding the timing and tolerances we would be dealing with, I made a spreadsheet in google drive:
https://docs.google.com/spreadsheet/ccc?key=0AnusyCQ3r42rdDdnZjZxNVZSNWhPZWJ2WFdLVDk4V1E&usp=sharing

At 3750 RPM (current speed of my engine running unloaded), I have about 8 milliseconds for calculations, during the period the exhaust valve is open. The current code takes less than half a millisec, so for now there's plenty of room for more calculations.

All the output signals are activated/deactivated from this ISR:

Code: [Select]

ISR (TIMER1_COMPA_vect)
{
  // grab counter value before it changes any more
  timer1CounterValue = TCNT1;  // see datasheet, page 117 (accessing 16-bit registers)

  // if just missed an overflow
  unsigned long overflowCopy = overflowCount;
  if ((TIFR1 & bit (TOV1)) && timer1CounterValue < 0x7FFF)
    overflowCopy++;

  curTick = (overflowCopy << 16) + timer1CounterValue;
 
  byte pin=interruptTable[currentInterrupt].edge.pin;
  if ( pin >= 0 )
  {
    digitalWrite( pin, interruptTable[currentInterrupt].edge.value );
  }

  logInterrupt( mCompareInt );

  currentInterrupt++;
  setNextTimerInterrupt(overflowCopy);
}  // end of TIMER1_COMPA_vect


Since the signals are all activated the same way, the delay for all signals is the same. The overhead for entering the ISR is about 3-4 usecs, the total execution time of an ISR like this appears to be about 30-40 usecs, which is within 1 degree of rotation at 3750 RPM (44.4 usec).

With the current setup, I only get one reading for RPM every two rotations, which apparently is enough for a generator, given that Les Banki also works with this.
However, I am thinking about placing a second hall sensor somewhere around the flywheel of the engine, so I get a reading every rotation.

Either way, for my current goal, getting a simple proof of concept prototype to work, the current system appears to be good enough to get the job done without the need for using assembler.

Quote from securesupplies on October 2nd, 2012, 02:14 PM

now a O2 sensor, small micro controller ( Arduino) and short program and you can control the air to fuel ratio.

Fuel injectors
adapt LPG GUys

https://www.youtube.com/watch?v=sAtDB2FCG...h_response

that link doesn´t work. please adjust. if it fails again please use quotation marks like

"https://www.youtube.com/watch?v=sAtDB2FCG...h_response"

thx

Quote from bussi04 on January 5th, 2014, 09:24 AM

Quote from securesupplies on October 2nd, 2012, 02:14 PM

now a O2 sensor, small micro controller ( Arduino) and short program and you can control the air to fuel ratio.

Fuel injectors
adapt LPG GUys

https://www.youtube.com/watch?v=sAtDB2FCG...h_response

that link doesn´t work. please adjust. if it fails again please use quotation marks like

"https://www.youtube.com/watch?v=sAtDB2FCG...h_response"

thx

It's probably this one:

https://www.youtube.com/watch?v=sAtDB2FCGYU

Looking for modern risk parts and  video hard ware lets build http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/integrated-host-processors/risc-microprocessor:MPC7448?tab=Design_Tools_Tab

welcome all parts vendors sites and training video to be post please so we select best to start this build  please post here or email daniel.donatelli@securesupplyusa.com

knock knock any one home

https://www.youtube.com/watch?v=WzSaYKxECVE

https://www.rs-online.com/designspark/bringing-multicore-to-the-arduino-world-with-shieldbuddy-tc275


found this to join  vmu with vic matrix  and speeduino