Show Posts
Pages: 1 ... 424 425 [426] 427 428 ... 582
6376  Using Arduino / Programming Questions / Re: Help! High Speed RS485 Serial Software on: May 28, 2011, 07:16:33 pm
Doh, yes that's right. A 10:1 difference isn't to be sneezed at smiley, still tight but not as bad as I said.

6377  Community / Bar Sport / Re: It's a good community ... on: May 28, 2011, 10:56:58 am
Yep sure is, I hang around a couple of forums and despite the occasional terse reply I'd say this is about the most cordial and non intimidating for a beginner.

Sometimes a google search takes me to a post on a forum where a noobie has asked a simple question and there's either been an RTFM response or none at all. 

6378  Using Arduino / General Electronics / Re: MOSFET for high speed PWM on: May 28, 2011, 10:51:38 am

40kHz is 25uS and you want 10th of a uS pulse so that's only a 250:1 ratio, I would think a timer with PWM would do that but I haven't tried it. You might have to settle for 2 clock cycles though (130nS unless you change the crystal).

6379  Community / Exhibition / Gallery / Re: Smart Home Manegment System on: May 28, 2011, 10:41:47 am
What comms do you plan to use between all the sensors and actuators?

6380  Using Arduino / Programming Questions / Re: Help! High Speed RS485 Serial Software on: May 28, 2011, 10:38:15 am
That's nearly a character every uS. If the data is non-stop you will never keep up. If it's in bursts you should be able to, but I don't know if the standard hardware serial library will cope, I doubt it because it uses interrupts and I can't see an interrupt approach working at this speed, it takes longer than a uS just to service the interrupt.

None of the softserial libs have a chance.

I think a very tight loop that polls the char available flag and saves to RAM would work.

How many bytes are you receiving and how often?

6381  Development / Other Hardware Development / Re: ATMEL Mega1284P evaluation board avalible on: May 28, 2011, 10:31:03 am
Argh, I miss using Altium. You are using one right?
I was a very early adopter of the original DOS-based Protel, I pushed for it at the company I worked for. Moving from stencils and Bishop tape to CAD was a real leap of faith in those days.

We used to get beta releases (from the guys who wrote it in Tasmania IIRC), we'd phone them and talk about features we'd like in the next release.

Despite Altium's heritage it's nothing like Protel, it's bloody good though.

6382  Development / Other Hardware Development / Re: ATMEL Mega1284P evaluation board avalible on: May 28, 2011, 06:50:32 am
I'd say the top left and bottom right mounting holes have components/tracks way too close, a screw head would easily short some of those tracks and maybe foul the headers.

6383  Using Arduino / Sensors / Re: 12V Battery monitor - current and voltage on: May 28, 2011, 03:13:33 am
So the big loads are off your start bank are they? I hope so because that's no way to treat deep cycle batteries smiley

The fore and aft thrusters will pull 600A+ in total (did I get the numbers right) so running both at once (does that ever happen?) will certainly draw a lot from the batteries.

Assuming you can measure that I'm not sure how you relate that to battery SOC as 1sec @ 600A is not the same as 600secs @ 1A because I'm sure the relationship is not linear.

I know that I need historic currents to be able to give a healt state of the battery bank.
Yep, I'm just talking about a SOC meter to tell you the current state of charge, that's different to historic logging to get battery health.

6384  Using Arduino / Sensors / Re: 12V Battery monitor - current and voltage on: May 28, 2011, 02:08:52 am
IIRC as a rule of thumb you charge wet cells at 10% of their AH rating, so for a 140A charging current you would need one heck of a battery bank. You have a 230Ah bank, so I would say anything more than around 20A would be an issue.

That makes the problem really easy, get an ACS712 current monitor chip, or read across a shunt with something like an AD8210.

To determine the SOC (state of charge) is harder, you have to implement "Pukets Exponent" (sp?) which basically says you don't get out of a battery what you put in. This is a number that you multiply the current out by (or I guess divide the current in) to allow for the inefficiencies in the battery.

Once again IIRC for wet cells the number is often used is 1.2, although in theory you should ask the manufacturer.

And of course you can't just read voltage to do this, you have to know the recent current history of the system, like whether the batteries were held in absorption for long enough etc.
It's a bit of a black art to which I'm not privy, still I think you can do a reasonable job with simple tools and algorithms.
6385  Development / Other Hardware Development / Re: ATMEL Mega1284P evaluation board avalible on: May 27, 2011, 10:48:53 pm
I wonder if your drill size problem was that the via "anulars" were too small, ie the copper around the drilled hole. This happens when the hole it too large for the pad according to the rules.

As for making components, I don't even bother to search for them, I just make things as I need them (but I don't use Eagle).
6386  Topics / Product Design / Re: Wanted: Arduino expert for Brisbane based Prototyping Project on: May 27, 2011, 03:36:58 am
I have a friend who got a product written by someone at coders-r-us or whatever, and to be fair the product was delivered at a price that would hardly have paid me for a day.


It took forever, maybe even a year I forget now. And EVERY tiny change takes a month.

Last I heard they had version 2 out, and had been waiting 3 months for the source code.

This probably isn't common (one would hope not) and certainly there are issues with hiring people as well. Just putting another perspective on the "argument".

6387  Community / Bar Sport / Re: Does anybody really know what time it is? on: May 27, 2011, 03:27:14 am
So I guess we'll all be dumping our RTCs and start using ATCs soon.

6388  Using Arduino / Programming Questions / Re: Fast Pulse Counter - High Speed Counter on: May 26, 2011, 09:24:45 am
I hope I haven't got my numbers out by an order of magnitude here smiley

Just looking at the three numbers you've got above


The difference in period between those three is < 1uS.

The "ISR"s you have aren't really ISRs at all, they are functions called by the the real INTx ISR, however as the real ISR doesn't re enable interrupts they are effectively the same thing but with a higher overhead.

Given that these two interrupts are asynchronous with the program and each other I reckon there are two potential issues.

a) The interrupt latency is variable, and with tolerances as tight as you have this could easily make a difference, ie the difference between getting a count of 7.543KHz and 7.530Khz 228nS or about 3-4 processor cycles.

b) If you are in INT0 and get INT1 (or VV) then the second interrupt will be ignored until you finish the first, meanwhile the timer is happily ticking away. Likewise if you are in the millis() interrupt.

I'm not convinced this can be totally overcome, but changing the "ISR" to something that did almost nothing like

volatile byte INPUT1_t;
volatile byte new_count_1;
void INPUT1_ISR()
  INPUT1_t = TCNT0;     
  new_count_1 = true; // set flag for external processing to occur

and doing all the other work in the main loop would have to help. At least then there's less chance of interrupts clashing. But there's still a chance and you have a double whammy, the higher the frequency the more likely to clash and the more affect it has on the count.

Interrupts are fine but they do introduce these sort of issues.

I think for high-speed counts using pulseIn() may be a better option. It is blocking but it sounds like you have known times, say directly after servicing the i2c protocol with the master, where you can afford to concentrate on this.

As pulseIn() does nothing but look at the state of a pin it is very deterministic, I would also kill interrupts around the pulsIn() call, this will affect millis() and maybe other things but you don't need them by the look of the program.

If the gadget is supposed to measure a large range of periods then a two-pronged approach may be the idea. PulseIn() for high speed and the other for low speed. Of course with pulseIn() you would have to measure both mark and space periods and add them together.


6389  Community / Exhibition / Gallery / Re: Greenhouse automation on: May 24, 2011, 07:03:47 pm
Thanks for the links,

I'm experienced in Wed dev and also embedded micros but have never tied the two together and that blog/tute gives me a better idea of how to do it.

I'd like to do this some day before too long, at present I'm designing a monitoring and control network ( and that is taking all my time and will for a while I suspect.

When it's running I'd like to be able to share data on the web like that.

6390  Community / Bar Sport / Re: Angle Trisection Approximation on: May 24, 2011, 06:10:26 am
That's pretty clever, but I know a better way.

Use compass to find straight edge, then use straight edge to hoke out calculator from behind the sofa where it fell the other day.

Then use the calculator smiley

Woops, there's a bug in that algorithm, compass has been defined as type "direction_finding_device", it should be "circle_drawing_device".

Pages: 1 ... 424 425 [426] 427 428 ... 582