Show Posts
Pages: [1] 2 3 ... 30
1  Using Arduino / Programming Questions / Re: Trying to get single button to start / stop a show - non-blocking on: July 14, 2014, 06:58:25 pm
The point that I was trying to make was not the variable names (even though I "corrected" their spelling in my example) but rather the ShowStarted!==showStated is an evaluation type statement. As such it should have something like "if(ShowStarted!==showStated)...." wrapped around it.

However, I had assumed that you made the mistake of using "=="  instead of "=" for the assertion of the value of one variable to another. Right or wrong, that was the point I was making. 
2  Using Arduino / General Electronics / Re: 4-20ma output from Arduino on: July 13, 2014, 06:18:35 pm
Accidently revisited this thread and saw thats its still alive.

but the author (as always on a forum) never gives the thumps up for what he/she did, that actually works.

I put it in the too hard basket and delayed the project, but I am now looking to revive it.
I have done a lot of Googling since and am leaning towards a simple  op-amp/transistor setup. Like the diagram below, but using an analogue pin and smoothing cap instead of the zenner to provide the input voltage.

I will prototype it in the coming days and  will make up my mind then.
3  Using Arduino / Programming Questions / Re: Trying to get single button to start / stop a show - non-blocking on: July 12, 2014, 07:36:47 pm
Quote
ShowStarted !== showStated

Is that meant to read "ShowStarted != ShowStarted" ?
4  Using Arduino / General Electronics / Re: 230V hakko FX-888D? on: July 12, 2014, 07:30:18 pm
Quote
..most cannot ship to me, or the shipping costs are stupid.

Buy the iron from the link above (https://www.sparkfun.com/products/11704) and it will cost $100 US with shipping to NZ of $42.60 economy or $56.60 expedited. Chuck in the transformer that I listed above (from NZ distributor) at $20. Total cost around $170.
Not bad for a quality iron. Sure its not as cheap as if we lived in US but you know that we have to pay more for living around this side of the world.
5  Using Arduino / General Electronics / Re: 230V hakko FX-888D? on: July 12, 2014, 04:48:06 am
Quote
Can anyone recommend where I should buy from.

For the Hako try

http://www.adafruit.com/products/1204

For the power coverter try Jaycar

http://www.jaycar.co.nz/productResults.asp?w=power+converter&keyform=KEYWORD&SUBMIT=Search

Scroll half way down the page.

OR

http://www.wallcann.com.au/100w-240v-to-120v-stepdown-voltage-converter.html?___store=default

It seems very cheap but is made in Australia and therefore has to comply with Aus safety standards (probably similar to NZ).
Says at the bottom of page " Servicing online and through outlets in Australia, New Zealand, USA and Canada."
6  Using Arduino / Networking, Protocols, and Devices / Re: simplemodbusslave with linksprite rs485 converter on: July 05, 2014, 08:55:02 pm
Without  source code and how you've wired up the arduino and converter there is not much that we have to work on to help you.
7  Using Arduino / Project Guidance / Re: Indoor Positioning system using Arduino on: June 28, 2014, 02:11:09 am
@GoForSmoke

Quote
As long as the robot is not moving....
True. The faster the robot/person moves the less accurate will be the read position. However far the robot moves in 300ms will be the inaccuracy. Through trial and error the delay period can be decreased thereby increasing the accuracy. Again, without knowing the details of the intended application we cannot know whether this inaccuracy is acceptable.

Quote
No. The flash of light would reach the corners in a fraction of a microsecond, unless a corner is over 300m away.

I covered this in Reply #18 when I said "...very minor difference (we are talking about the speed of light over a few metres) in the time...".

Quote
At that point there would be a very small known delay for the sensors/brain to process an interrupt and ready for the ping.

Thats what I was referring to when I wrote "..the latency involved in the process of sending and receiving the infrared.." The operative word here being "process".  It covers everything from executing the code to turn on the infrared through propagation of the light waves to the receiver, to processing of the received signal by the micro at the other end.

Quote
The ping sent by one source, the corners only need to know the relative time post-known-delay to be able to calculate position.


I'm not clear on what you mean here. Are you changing the paradigm to a scenario where the ping is sent from the robot/person and is received by the corner units?

Quote
I'd use relative time because speed of sound changes with temperature and to a lesser extent, humidity.
Fast air flow in the room could fuzz that a bit but fast would be percent relative to speed of sound.

I think over a distance of 10 metres in an indoor environment, this will not be an issue. I made an ultrasonic dam level control (using a Maxbotix sensor) for a farm that this year has had temperatures between 42° C to -9° C  and on occassions, thick fog (i.e. 100 humidity).  The water level range was 8 metres. An external data logger used to verify its operation indicated that it was within 2 cm of true reading despite the wide range of environmental conditions.

I think the OP needs to specify his desired level of accuracy. If he/she wants it down to 0.5mm then he/she can spend a few thousand dollars on an autotracking Total Station. Compact, easy to setup (easier than laying down a wire grid on the floor that would require kilometres or wire for the area in question) and highly accurate but as usual, the cost/benefit trade-off.

 



8  Using Arduino / Project Guidance / Re: Indoor Positioning system using Arduino on: June 27, 2014, 11:02:03 pm
Quote
Since the start the OP has been clear that the room should know where the person carrying the tag is, not the other way around. The robot is a strawman.

When I read the OP, I didn't read it that way but you could be right. If my assumption is wrong then hopefully the OP can clarify the intended use of the system. If so it makes the solution easier still which I will bother going into if the OP gets back to us.
9  Using Arduino / Project Guidance / Re: Indoor Positioning system using Arduino on: June 27, 2014, 10:09:27 pm
Quote
If the corner units all ping together then how does the robot know which is which even without considering echoes?

In my previous post I said, "To avoid the collision of pings there would be a set delay of say 100ms between corner modules."

With such a large delay (it could be made smaller with experimentation) one would know that the first ping (and following echoes) came from corner unit #1. The second ping that arrives 100 ms later (after all the echoes from the first ping have died out) is from corner unit #2 and so on.

Quote
If the robot flashes a light then that sets a start time for each sensor to wait for the first sound ping (echo takes longer to reach).

Not sure what you mean by this. The robot (or person carrying device) would send an infrared pulse and use that as the start time. The latency involved in the process of sending and receiving the infrared would need to be calibrated into the calculation, as mentioned. It would then listen for the return pings, caculating out the delay on the #2, #3, and #4 corner modules.
10  Using Arduino / Project Guidance / Re: Indoor Positioning system using Arduino on: June 27, 2014, 09:47:19 pm
Quote
...the sensing units only have to receive but they should be connected to a single "brain"

The sensing units on the robot are connected to a single arduino (the one running the robot.)  The units in the corner are for pinging only; reflections ignored.

Another maybe simpler version is to not have the robot initiate the pings. i.e. skip all the infrared gear in my previous post.

The corner units have their interupt pins connected together and a pulse is delivered to all units simultaneously at a rate of, say, 1 Hz.

The robot would not be able to determine the absolute distance from each corner unit as it has not initiated the ping but from the relative timing of the four pings being received roughly every second, it could calculate the relative distances to each corner unit and therefore it position in the room.
11  Using Arduino / Project Guidance / Re: Indoor Positioning system using Arduino on: June 27, 2014, 09:03:38 pm
Due the high speed of radio transmissions and therefore the low margin for error in timing I think the OP will run into problems with achieving acceptable accuracy.

A slower propagating wave such as sound might be a better option and also the primary elements are already available. Without a description of the end use of the system it is hard to tell whether the compromises involved would be a deal breaker. I make the assumption that the OP wants to use the location system for robots in a room. Therefore I ask if the 50 metres is overkill. The system I propose may would be limited to a room/area somewhere beyond 4 metres and maybe beyond this (see explanation later).

An ultrasonic sensor (e.g. SR-06 or better spec unit) would be placed in each corner of the room. Each of these units would be connected to their own, dedicated arduino (or simple Atmega85/168/328 chip) with an infrared sensor also connected, through appropriate supporting circuitry, to an interupt pin of the Atmega. The robot somewhere in the room would have two or more SR-06 units to accept the pings that will come to it. When an infared pulse is periodically sent from the robot to the coner modules they would fire off a ping from their SR-06 and would ignore the reponse. To avoid the collision of pings there would be a set delay of say 100ms between corner modules. e.g. corner unit #1 one pings instantaneously on receipt of pulse, corner unit #2 100 ms after receipt of pulse, corner unit #3 200 ms after receipt of pulse, corner unit #4 300 ms after receipt of pulse. these delays would be accounted for in the final calculation in the robots micro.

The robot would receive these pings, and triangulate it position from the timing of these pings. There would be a propagation delay involved in sending, receiving and and processing the infrared pulse before a ping was fired which would need to be calibrated. Its not as accurate as pulsing an arduino pin directly connected to the trigger pin of the SR-06. Likewise there may be a very minor difference (we are talking about the speed of light over a few metres) in the time when each corner module received the infrared pulse depending on how far the robot is from each corner unit. Maybe assembler would be required to optimise the timing.

The SR-06 is rated to 4 metres however this is the sending the ping over this distance and the very much weaker reflection over the same distance. If the ping is from device to device without the very attenuating reflection, I think much greater distances could be achieved; 10 metres plus?
12  Using Arduino / Programming Questions / Re: Progmem won't work with variable for index; only static values on: June 15, 2014, 07:10:01 am
Thanks Coding Badly.

Quote
What @gardner posted is not a work-around.  It is correct.

I can't find any other examples on the net that  require one to use pgm_read_word() before using pgm_read_byte().

I had read that  documentation that you refer to  (http://www.nongnu.org/avr-libc/user-manual/pgmspace.html) several times prior to posting this thread.

The documentation does not suggest that I use both routines to extract bytes. In relation to reading strings it states:

"You probably don't want to pull the string out of Program Space, byte by byte, using the pgm_read_byte() macro."

It so happens that I do, so the pgm_read_byte() macro is for me. It does not state that I also need to use the pgm_read_word() first.

The caveat at the bottom of the AVR-Libc documentation states that there is extra overhead incurred by these routines. So it would be best to run just one instead of two. Of course if this is the only way to do it, then one has to live with the overhead. But if it isn't, then i'd rather not.

The fact that the pgm_read_byte() runs fine with the static values seems to prove that one does not have to use the pgm_read_word()  prior to using the  pgm_read_byte().

Quote
No.  It's a bug in your code.

Please would you point out specifically where the bug is in my code?


EDIT:
I've played around a bit more and have the following alternative code working fine (which shows that you don't have to use pgm_read_word()  prior to using the  pgm_read_byte()) but it still doesn't explain why the original code does not work.

Code:
#include <avr/pgmspace.h>

PROGMEM const char BitMap1[] = "abcdefgh";
PROGMEM const char BitMap2[] = "ijklmnop";

PROGMEM const char* const progbytes[] =
{  
  BitMap1,
  BitMap2
};

 
void setup()
{
  Serial.begin(9600);
}

void loop()
{
  for (int j = 0; j < 2; j++)
  {
    for (int i = 0; i < 8; i++)
    {
      byte var = pgm_read_byte(&progbytes[j][i]);
      Serial.println((char)var);
    }
  }
  while (true);  // loop forever  
}

Now I'm just comparing it to my code in my first post in this thread to see why this one works and the other one doesn't.
Still can't see it, can you?


13  Using Arduino / Programming Questions / Re: Progmem won't work with variable for index; only static values on: June 15, 2014, 12:30:03 am
Thanks gardner for the workaround.
However why is it that I do not have to read twice when I use, say:
Code:
byte var = pgm_read_byte(&(progbytes[2][10]));
but I have to read twice when I use :
Code:
int x = 2;
int y = 10;
 byte var = pgm_read_byte(&(progbytes[x][y]));

Is this a bug in the Arduino IDE?
The AVR-Libc documentation does not state that you have to use  pgm_read_word prior to using  pgm_read_byte.
14  Using Arduino / Programming Questions / Progmem won't work with variable for index; only static values on: June 14, 2014, 08:31:58 pm
I have a problem with progmem using variables for its indexes. When I insert static values for x and y in the code below (e.g. byte var = pgm_read_byte(&(progbytes[2][10])) );, it accesses the array correctly. But when I revert to the variable values, it retrieves garbage.

Code:
#include <avr/pgmspace.h>

PROGMEM const char string_0[] = ":1000000005C1000022C1000020C100001EC1000087";
PROGMEM const char string_1[] = ":100010001CC100001AC1000018C1000016C1000078";
PROGMEM const char string_2[] = ":1000200014C1000012C1000010C100000EC1000088";
PROGMEM const char string_3[] = ":100030000CC100000AC1000008C1000006C1000098";

PROGMEM const char* const progbytes[] =
{  
  string_0,
  string_1,
  string_2,
  string_3
};

void setup()
{
  delay(1000);
  Serial.begin(19200);  
  Serial.println("Starting");  
    
  Test();  
}

void loop()
{    
}

void Test()
{
  for(int x = 0; x < 3; x++)
  {    
    for(int y = 0; y < 10; y++)
    {      
      byte var = pgm_read_byte(&(progbytes[x][y]));
      Serial.print("x: ");
      Serial.print(x);
      Serial.print("    y: ");
      Serial.print(y);
      Serial.print("     ");
      Serial.println((char)var);
    }
  }
}

Does anyone have a fix?
15  Using Arduino / Microcontrollers / Re: Help programming .hex bytes to flash on: June 12, 2014, 05:29:25 am
Quote
The standard bootloaders don't deal with .hex files at all; the .hex file is converted to binary on the PC side

Does this mean that if I copy the hex values into flash at the addresses indicated in the hex records, the program/sketch will not run?
Pages: [1] 2 3 ... 30