Show Posts
Pages: 1 ... 87 88 [89] 90 91 ... 93
1321  Using Arduino / Project Guidance / Re: Balloon SSID location without Wifi shield or GPS on: September 24, 2011, 03:58:29 pm
I've been working on sampling and sending audio for a different project.  They said that couldn't be done either, without a sharp low pass filter!  Proved them wrong.  Plenty of processing power left over. 

Sent a few balloons up with 100g and they went over the mountain with altitude to spare!  Not sure what they did on the other side.  Haven't tried for awhile due to clouds.  I imagine they went 10+ miles but no one called the number I wrote on them.  Maybe they're still up?  smiley-wink  I've realized that the weight of the bag is negligible compared to the payload beyond 2m width.  So the capacity is proportional to the length cubed (volume).  I'm going to go bigger!  Using cheap tape, quality control becomes an issue until I learn a better technique.  I'm thinking I might get up a Razr cell phone and small GPS.  Optimistic still?  @Zoomkat - Payload Mass = C x Volume.  They can carry humans.
1322  Using Arduino / Project Guidance / Re: EEPROM better than SD card for audio ? on: September 24, 2011, 03:30:02 pm
Can't you read an SD card like Openlog at 115kbps?  It's buffered so the code doesn't have to wait for each byte to arrive?  I've been going the other way at this speed, so mine is much more difficult.
1323  Using Arduino / Project Guidance / Re: Voice Wifi Transmission Project on: September 24, 2011, 01:53:12 pm
Without uLaw compression, if the scaling is done in hardware, the main loop is only 2 lines of code:


About 20 lines with both of those features.
With a few more lines of code I've used oversampling to eliminate the need for a Nyquist filter, even at 2Khz.

At 10khz over XBee it sounds better than a mobile phone!

At 32khz you cannot send it in real time serially, but you can send chunks for analysis on a PC.

I recommend this, they're Free!
1324  Using Arduino / Project Guidance / Re: Voice Wifi Transmission Project on: September 24, 2011, 01:27:18 pm
I've got it working.  You cannot store 10s obviously.  You must send it immediately to the PC.  This is no different from a cheap wireless microphone except in the following ways:

1. XBee can go to sleep when sound is below a threshold.  UNO can also, waking up to sample every 10s.  The average power is less than 1ma.  Try this with a wireless Mic 1/2mi away!

2. Other data can be sent too.  IR sensor, temp, light, jpg. 

3. You can look for a signature in the frequency domain before sending.  There is enough processing power for this!  For example birds, a specific type of owl already sampled, male voices, a car engine idling, heater turning on, transient sounds like a door shutting.

4. You can talk back

5. Do a FFT at 32khz and only send the results instead of the audio

6. Using Openlog you can make a tiny Spy Bug with a thumbnail sized lithium thionyl battery that lasts a YEAR!  Depending on how much talking is being done.  Try that with a voice recorder?

Which of these 6 features do you like?
1325  Using Arduino / Networking, Protocols, and Devices / Re: XBee ADC standalone on: September 24, 2011, 11:31:46 am
No caps or resistors needed?  Depending on the signal of course.  It is very cool! 

But 1khz is not fast enough for audio.  It is the maximum for the XBee alone.  Instead I'm oversampling at 32khz, then sending 4khz after averaging every 8 samples.  This way I don't need a low pass filter.  I could choose to send 8khz or 20khz data every other buffer.  This is used to do a frequency transform.

Someday I will think of an application for the XBee standalone...

1326  Using Arduino / Networking, Protocols, and Devices / XBee ADC standalone on: September 20, 2011, 02:38:53 pm
With just a couple of AT commands I've got my XBee sending audio from a Mic at 1khz rate.  Right now it's attached to the Uno, but the Uno is doing nothing.  What pins do I need to provide for the XBee to work like this on it's own?  Gnd, Pwr, signal?  Anything else?

1327  Using Arduino / Project Guidance / Re: Interrupts during Serial output on: September 18, 2011, 04:20:30 pm
Wouldn't this allow the processor to be totally free to manipulate the higher frequency 8khz samples I've taken in 1K RAM?  I realize this is only 1/8th sec.  Once I've done that, I wouldn't have to store/send them.  Just store the short results to Openlog, while the XBee is sending the LoFi audio for me to hear.
1328  Using Arduino / Project Guidance / Re: Interrupts during Serial output on: September 18, 2011, 03:29:46 pm
Another idea, on a different track.  I wouldn't have to write any code.  I wouldn't even need a controller!
On either end.  Could just hook 2 XBees to 2 amps, Mic, Speaker to hear it.

But it's only 1khz.

Of course this is not what I'm trying to achieve, but how Cool!
1329  Using Arduino / Project Guidance / Re: Max speed XBee on: September 18, 2011, 09:12:09 am
The distance is variable.  I have the 60mw model.  I'd like it to go full speed at 50m.  Slower at 1/4 mile in the woods.  Already this is working if I choose the appropriate delay in advance.  I want it to figure it out by itself as the conditions change.  Each byte delay should be different depending on if the XBee buffer is near full.  Not a constant delay between characters. 

In other words, I want to pause then the buffer is full.  Using CTS pin?

I didn't say I was storing 2K of data.  I'm sending audio data in real time as it's being sampled.  But only sometimes in blocks of 2K or 4K.  Should be able to send 8K if I can keep up.  It works great at 1/2 the speed.  This means sampling at 4khz.  I'd like 8khz.  This full speed works at a close range only.  So I've got everything I need already working.  Except I don't want to decide in advance which configuration to use.  How do I know when to slow down?

For example, I could send small 100 byte buffers at full speed without losing any data because of the Xbee transmit buffer.  If I can't keep up because the distance is too great, send the next one at 1/2 speed by averaging each pair of bytes.  Maybe 1/4 speed instead.  All I need is to be able to read CTS from XBee.  How do I wire this?  Is it already connected to Reset?  I have the Sparkfun shield.
1330  Using Arduino / Project Guidance / Re: Interrupts during Serial output on: September 18, 2011, 08:35:47 am
According to what I've read, you have to disable interrupts during serial transmission.  I assumed this is because you don't want it to be interrupted in the middle of a string of 8 bits?  Maybe this is wrong?  Is it as simple as you say?  Just send it in loop without turning off the interrupts to service the Mic?  That makes sense since the Serial.write call only takes a few uSecs anyway.  You wouldn't be interrupting the UART itself.  It is unlikely the write call would be interrupted if it's being called when the 1 byte buffer is empty.

If I do have to disable interrupts, it wouldn't delay the Mic sample much, only a few uSecs, not milliseconds.  The key is to avoid waiting for the 1 byte buffer.  Maybe interrupting this wait is bad?  Probably not.

I've realized the transmit buffer before the UART is only 1 byte.  But in the XBee it is 100?

The code will slow down on it's own waiting if the 1 byte buffer is full.  But I have to monitor CTS to avoid filling the bigger one.
1331  Using Arduino / Project Guidance / Re: Interrupts during Serial output on: September 18, 2011, 02:55:50 am
Sure, Circular/ring buffer.  I understand that part.  But if I send it to the serial port in loop, I have to disable interrupts for each byte sent.  Otherwise the ISR will interrupt the serial routine.  If I send more than one byte, the interrupts will be disabled for too long and I'll miss a Mic sample.  So I have to send one byte at a time then check for (enable) interrupts to sample the Mic.  If that's the deal, why not just send 1 byte at a time within the ISR?  My first experiment will be simple, the byte I just got.  Then add the ring buffer.

Can I send 1 byte from within the Mic sampling ISR?  There is no delay, assuming the buffer is empty.
1332  Using Arduino / Project Guidance / Max speed XBee on: September 18, 2011, 02:45:02 am
Let's say I wanted to send 2K of data as fast as possible from the Xbee on Uno to PC in transparent mode.  I've got it working using a short delay between each byte at 115Kbaud.  I arrived at this thru trial and error.  I'm getting 10.8KB/sec.  All the data goes without any errors or lost bytes.  Until you put some distance between them.  Now my delay is too short because of a few retries.  I'm trying to send a byte before the last one was sent. 

Can I use the hardware CTS pin from XBee to fix this?  My plan is to wait when the CTS line from XBee says it's full, until it's ready.

I tried increasing my delay between every byte, even the ones without retries, but then I only get 1/2 the speed.
1333  Using Arduino / Project Guidance / Interrupts during Serial output on: September 17, 2011, 05:25:56 pm
Thinking out loud here.  Please help!

I wrote a routine to sample the Mic at 8khz with interrupts in CTC mode it works! As you know the available RAM is only 2K. What to do with all this data?  I could write it to Openlog, USB, or Xbee.  All of these are Serial.  115kbaud is fast enough.  But whenever I write a character or buffer I have to turn off Interrupts first.  If I send more than a character at a time without servicing the Mic interrupt I will miss sampling the Mic on time.  These 2 speed, in and out, are about the same so I can't even send 2 characters in the time between Mic samples.  How do I send data serially without waiting for the buffer to finish sending?  During this time interrupts are disabled.

After more research I see that I can send ONE character without waiting, assuming the single character output buffer is always empty.  There will be retries with XBee so this might not always be true.  Or 2 characters and only need to wait for the 1st to send.  This does not help much for a buffer of size 100.  I still have to wait to send 99.

Let's keep it simple:
Can I send 1 byte each time from within the Mic sampling ISR using Serial.write? 

In this case can I leave Interrupts enabled since I know it won't be called twice?  Does Serial.write or Serial.print disable interrupts?  If so I'll just re-enable them.  I guess I have to do this anyway since I'm in an ISR.  I guess my real question is can I call Serial.write from within an ISR?  Anything special I need to do first?

Let's assume that'll work.  Please correct me if I'm wrong.  I should test it.  Now I'm going to get more complicated.  Let's say I want to modify the data in a buffer before sending it serially.  Can I use a small circular buffer for this?  Instead of sending each byte as it's received from the Mic directly, I can store it in the buffer in the ISR, then send the next single byte from the other side of the circle, all within the ISR.  1 byte in, 1 byte out.  Who says I have to send the byte I just got?  Noone right?

Sounds good?
1334  Using Arduino / Networking, Protocols, and Devices / XBee ACK failure count utility on: September 16, 2011, 12:40:53 pm
I've learned a few things about the XBee Pro type 1 today.  I wrote a utility to aid in range testing and reliability measurements.  I've noticed that the signal strength goes to the lowest level as you walk away long before the data stops coming reliably.  S/N ratio is a much more important measurement than just RSSI.  It's easier to display or record ACK failure count change per minute.  This is a more useful number because it measures what you want.  The data flow! 

The first thing you should do is measure the energy level in each channel at the location where the majority of your equipment is.  This is caused by interference from other digital circuits.  Most people will use the XBee Explorer hooked to their PC.  If you're collecting data than the energy measured here is by far the most important of the 2 locations.  Of the 12 Channels I've found 1-2 are usually very noisy.  1-2 are quiet.  Pick one of these!  It's easy using my Sketch.

I've tested a few antenna designs.  Wanted to find something simple and small to go with the wire antenna on the XBee.  Did some testing with the bottom end of a Bud can.  It's roughly parabolic shaped like a DTV dish.  In theory this should work at the proper distance from the element.  Maybe, but in practice, in the woods, it is very hard to adjust the distance and aim.  It worked better without the can.  Until...

One time by mistake I turned it around the wrong way so the convex side was facing the antenna.  In theory this should not work, but in practice it does!  Remember there are many wet trees, bushes, rocks, terrain, reflectors all around me deep in the woods.  What the convex side is doing is spreading out all the energy that would have been wasted going the wrong direction, but at least now in the right 180 deg half, towards the target.  Some of these reflected waves find their way to the receiver.  No more aiming!  Without the can, you have to aim the wire antenna in a horizontal plane.  Not left and right, but up and down.  There are many lobes with the strongest being not where you might expect.  With the convex can, this problem goes away!  Try it?

The results would be different in space, or even in the desert.

My conclusion after testing in many locations and with different variables:
It does NOT increase the range, assuming you aim the stock wire properly.
But it makes the aiming requirement of a simple wire go away!
You don't even need a signal or Sketch running to test the remote setup anymore.
1335  Using Arduino / Project Guidance / Re: Very Sensitive microphone/sensor for 'stethoscope' ? on: September 14, 2011, 12:55:24 pm
You can get / I've got free samples:
The socket is $3.

With this:
I can literally detect a pin dropping.
I've modified the circuit a little.
Pages: 1 ... 87 88 [89] 90 91 ... 93