Show Posts
Pages: [1] 2 3
1  Forum 2005-2010 (read only) / Syntax & Programs / Re: Trouble Converting 3 Bytes to a long and printing on: March 29, 2010, 02:24:08 am
As Wire.Receive() returns a byte, I suggest you use casts to ensure that your result really is a long

a = ((long) Wire.Receive() << 16) | ((long) Wire.Receive() << smiley-cool | ((long) Wire.Receive());
2  Forum 2005-2010 (read only) / Syntax & Programs / Re: Feasibility with Arduino on: March 29, 2010, 01:57:48 pm
There are published functions for measuring the amount of remaining memory (stack and heap).  Amount of Flash memory and EEPROM is fixed depending on the Atmega chip used (Atmega168 vs Atmega328).

Look here

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1213583720/19
3  Forum 2005-2010 (read only) / Syntax & Programs / Re: Steeper motors simultanious on: March 29, 2010, 11:36:38 am
So you want to control two steppers with one H-bridge?

You could use a solid-state DPDT relay to switch between motors?  Probably too slow though.

As for 'releasing' the motors, the datasheet for H-bridge show the ENABLE pins, hard-wired in the circuit to V1 and V2.  If you could instead control the ENABLE signal with an Arduino pin instead the outputs switch to high impedance and the output to the motor windings shut off.


4  Forum 2005-2010 (read only) / Syntax & Programs / Re: Steeper motors simultanious on: March 29, 2010, 02:11:14 am
Dumb suggestion (not knowing your configuration) - wire both steppers to the same control pins?
5  Forum 2005-2010 (read only) / Syntax & Programs / Re: editing certain digits in a number on: March 29, 2010, 02:40:07 am
A minute is 1/60th of a degree, you can't just pull out selected digits - it needs to be scaled to get decimal degrees.

Minutes / 60


4226.5057,N,08152.7644,W

42 degrees N
26.5057 minutes / 60 = 0.44176 decimal degrees
42.44176 degrees

081 degrees W
52.7644 minutes / 60 = 0.87941 decimal degrees
081.87941 degrees
6  Forum 2005-2010 (read only) / Syntax & Programs / Re: PID problem with speed controll on: March 29, 2010, 02:02:46 am
Also if you are measuring speed, your docalc() function would normally reset the motor and encoder counters to zero, so that you know the number of units change per time interval.
7  Forum 2005-2010 (read only) / Syntax & Programs / Re: PID problem with speed controll on: March 29, 2010, 02:00:13 am
Arduino can read many thousands of digital inputs per second, especially if you use interrupts as you are doing.

Don't put Serial.Print calls in your interrupt service routines - that's a sure way to slow things down.

If you are using a quadrature encoder, in the interrupt service routine you need to check the state of the B pin input, to know whether to increment or decrement your counter (due to the direction of rotation of your encoder).
8  Forum 2005-2010 (read only) / Interfacing / Re: Sending X Y Coordinates Through Serial USB? on: March 29, 2010, 01:43:10 am
You could send your X,Y coordinates in "binary" or "ASCII decimal number strings".  If you use a single 8-bit byte to send a value, yes you are limited to 0-255 ... but if your data object is two bytes, you get 0-65535, and so on.

Taking the binary approach may be a little advanced for you, so consider a second approach:

Assuming X=123 and Y=56, have Processing send "123,056\n" - to keep things simple, make sure each coordinate is 3 digits - to the serial port on which the Arduino is listening.

The Arduino code reads one character at a time starting with the X coordinate numbers 1-2-3, recognizes the comma as a command to start receiving the Y coordinate numbers, receives the Y-coordinate numbers 0-5-6, and recognizes the newline character to start looking for the next X value.  This is called a simple "parser".

If you look at an ASCII character set you will see the numbers 0-9 grouped together, which makes it very convenient to convert ASCII numbers to binary ... just subtract the character '0' from each ASCII number character received.  So '1' (which is decimal 31 in the ASCII table) minus '0' (which is decimal 30) = 1.

So back to the Arudino code loop.  Receive the first character '1' which you know is the hundreds digit, subtract '0' to get 1, multiply this by 100, and save it in a variable = 100.

Now receive the next digit, the tens digit '2'.  Do the '0' subtraction to convert to binary 2, multiply by 10 making it 20, add to the variable saved previously - now you have 120.

Now receive the last digit, the ones digit '3'.  Do the '0' subtraction to get binary 3, no need to multiply, add to the variable saved previously - now you have 123.

Now receive the next character - it is comma - set a flag in your code to start receiving the Y coordinate.  Process the characters 0-5-6 in the same manner as for X.  When the newline character is received, the code reverts to receiving the next X coordinate.



There may be a function Integer.ParseInt() which does the same thing for you, but you will still need to detect the comma and newline and "split" the input characters into 3-character strings for the X and Y values.

9  Forum 2005-2010 (read only) / Interfacing / Re: FM Transmitter Church Project on: March 29, 2010, 03:25:47 pm
I mean, it will work to send the audio - if you use 8 transmitters.

To use 1 transmitter requires some kind of multiplexing scheme, requiring either the transmitter to jump very rapidly - 200 KHz? - through the 6-8 receiver frequencies (undoubtedly causing a great deal of switching noise), or combining the multiple audio channels into a single complex waveform and extracting individual channels at the receiver end ... very advanced DSP work, I imagine.  Either will be too much for a lowly Arduino, I fear.
10  Forum 2005-2010 (read only) / Interfacing / Re: FM Transmitter Church Project on: March 29, 2010, 03:17:49 pm
Looks like I completely misunderstood smiley-razz overlooking the word 'monitor' - you want to transmit TO the performers?

Seems to me your most recent solution will work as-is, to send the audio.

Turning to use of an Arduino as a controller (enabling/disabling individual transmitters) that should be much simpler.  How about an RS485 or RS-422 multidrop interface connecting the controller and the transmitter Arduinos on a common bus.  Each Arduino has a unique ID and only processes data stamped with that ID.  Once the electronic interface is taken care of, the code in each Arduino will be quite simple.

Maybe you could start with this http://www.arduino.cc/playground/Learning/DMX

11  Forum 2005-2010 (read only) / Interfacing / Re: FM Transmitter Church Project on: March 29, 2010, 02:25:35 pm
The radio kit he's looking at supports a wide range of frequencies, the trick is to lock transmitter & receiver pairs onto individual frequencies, and provide a nice, smooth way of selecting all or multiple to gate into the mixer.  Transmitter licensing is another matter.


A pretty cheap approach that avoids RF completely would be to find a circuit to modulate an infrared IR LED with the microphone.  Build 6 all identical, use a single IR receiver to demodulate them all.  If you wanted to select individuals and turn on/off their microphones, or adjust modulation level, build an IR detector into the microphone - give each mic a unique address using switches - and send commands addressed to the mics with an IR 'commander'.

I'm not saying this will be reliable enough to work, but it sounds like an interesting project.

12  Forum 2005-2010 (read only) / Interfacing / Re: FM Transmitter Church Project on: March 29, 2010, 01:08:28 am
I have my doubts that a single receiver could produce usable audio when it was transmitted by multiple transmitters sending on the same frequency.  Maybe it could work using some kind of frequency-hopping or time-division-multiplexing scheme ...

A brute-force approach ... 6-8 transmitters each on different frequencies, received by 6-8 receivers tuned to those frequencies.    Have we reached $600 yet smiley   Take the audio output from those receivers to an audio mixer board, perhaps retransmitting the resulting combined audio on a 9th radio to the congregation.

A variation ... the same 6-8 transmitters on different frequencies, and modify the receiver to make it easy to select the desired frequency - as in a "channel number".  If this is what you are asking, it would probably be relatively simple.

The benefit of the first approach - you could have multiple live microphones.  The second would only permit one at a time.
13  Forum 2005-2010 (read only) / Interfacing / Re: Using visual studio to control a stepper motor on: March 29, 2010, 01:16:48 am
The simplest is for the Arduino board to generate the pulses to the stepper, then you could change it's software to accept typed commands like "+100" - meaning step in forward direction 100 steps, "-100" to reverse 100 steps, "C+500" to step forward continuously at a rate of 500 steps/second, etc.

Initially, use the Arduino IDE's serial monitor to type and send commands directly to the Arduino.  Or Hyperterminal.  Once your command set is debugged, write a Visual Basic program that sends the same commands to the serial port.


14  Forum 2005-2010 (read only) / Interfacing / Re: Reading Temp Sensor from Car Engine on: November 25, 2010, 01:09:04 pm
You could also use the MPGuino platform http://ecomodder.com/wiki/index.php/MPGuino, and do some reprogramming to display oil pressure and temperature instead of fuel economy.
15  Forum 2005-2010 (read only) / Interfacing / Re: detecting obstructions on the sea on: November 25, 2010, 01:51:28 pm
This sounds similar to a problem I've been thinking about - aircraft anti-collision methods.  In such a case you want to have as many seconds of reaction time as possible.  In your case fortunately the solution is 2 dimensional and restricted to a few degrees of angle off the bow (unless you are detecting torpedoes coming from any direction!) - not 3D as in aircraft.

Usually this is solved with radar or radio-frequency transponders, but I've been thinking "passive detection" - whether detecting motor ignition noise, audible or ultrasonic "wind noise", sonar-like devices, infrared heat detector, cameras looking for moving light or dark objects, etc.

So far the most promising is the camera - using Optical Flow analysis techniques.

In your case, I would imagine something like a forward-looking Fish Finder (sonar) would be the answer?  I have no idea whether it would work, for example would the "clutter" caused by the water-air interface (waves!) make it totally useless?

By the way, you don't mention the speed which your USV is moving.

http://en.wikipedia.org/wiki/Sonar and the related http://en.wikipedia.org/wiki/SODAR (which sounds useless in my application due to the size of the equipment!)
Pages: [1] 2 3