baud rate autodetection on AVR 8-bit?

:

a pause.

nd you will (usually) discard info while you are deciding. Then, even if yo ur hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit...

e in a known way, reliable.

e
d

mple

es

om

at

I don't get it. If you got a hole for RS232 cable, you certainly can run an (water-proof) antenna through the case. 20 meters is no big deal for 802.15.4 (or ZigBee).

Yes, it's difficult to time-stamp the receiving end, but you can always time-stamp the transmitting end. We put timing data in the packet itself.

Reply to
linnix
Loading thread data ...

That's nice for some purposes, not nice for others. For example, if you are designing an instrument (which is what I do for work) that may be part of a closed loop control system (such as, for example, a GaAs boule puller) then time stamps do NOT HELP you at all. What matters entirely is the rigorous repeatability of the phase delay of measurements and smaller loop times. You want a very short loop and zero variance in the measurement timing (a delay cannot be avoided, but what you need _most_ is no variation of that delay -- it must be the exact same value every time, if possible.)

Jon

Reply to
Jon Kirwan

There is limited space on the end caps for new holes. There is already a hole for power and RS-232/USB which needs to be there as the power is plugged/unplugged at that connector.

It's also more than a hole---it's an underwater bulkhead connector that costs about $100 and has to hold pressures up to 5000PSI. That last requirement is a step above "waterproof". Next there's the problem of getting the signals through the aluminum or steel bulkheads and watertight doors.

Another issue with Zigbee is configuring the radio addresses so that the host communicates with the proper instrument. That's a bit more complex than plugging in the connector and selecting COM1.

That is the case with most instruments I've designed in the last decade. Oceanographic instruments have long service lifetimes. The one I am redesigning now was first operated in 1990. It used clocks, counters and CMOS logic state machines to feed data from an ADC to a UART and up an RS-485 cable about 500m to the surface. The data was streamed in 2- byte pairs at near the cable capacity at 115KB. Since there was no RTC in the subsurface system, the surface program was responsible for time- stamping the data, merging it with GPS data, and recording.

My goal for the near-term replacement of the subsurface instrument is to be able to use the same surface software----which means duplicating the timing of the old instrument.

Mark Borgerson

Reply to
Mark Borgerson

exact same delay every time

Jon

Reply to
Jon Kirwan

Time stamping at the source helps in many situations, however, you _need_ a reliable timing generator at the source.

Of course, if the source device is connected to a good GPS or IRIG time source, things should be pretty easy.

However, if you have to synchronize the local clock at the signal source over the same serial link, there are a few pitfalls, mainly to various jitter sources.

In order to avoid these jitters in serial communication, you may have to use something like NTP (Network time protocol) adapted for serial links, in order to average out jitter in individual synchronization attempts over the serial link.

Of course, the NTP principle assumes equal propagation delay in both direction, which can usually be achieved in serial communication.

Reply to
upsidedown

In Jon's application, the communications link is part of the control loop. It's the actual jitter on that that's the problem - it doesn't matter how accurately you time when the datum was produced at the device, the controller, at the other end of the communications cable can't generate a response until that datum actually shows up.

A USB isochronous pipe might fit the application, although certainly not at the distances he's talking about.

Reply to
Robert Wessel

Exactly. The analogy I like to use is this:

Imagine you need to poke a long, thin, flexible bamboo rod into the entry hole of a bird house. You only get to hold the rod at the end and the hole is at your eye level 50' away. Now generalize this idea for the above: the length of the pole is the loop delay. It is easier to do if the pole is short. VERY MUCH easier, in fact. Distance makes a LOT of difference -- it's non-linear. Then also, now imagine that the length of the pole is varying all over the place as you try? The less variation in length there is, the easier the job is. No variation is best, even if you are stuck with a very long pole -- because you can design an algorithm that can anticipate the flexing, at least. But if the length is shifting almost at random, it greatly complicates any attempt to design such an algorithm.

Of course, it's dead easy to design an algorithm with a short rod. The changes in control at your hand are immediately reflected and so it's child's play then.

Anyway, that kind of gets the idea across. Time stamping will tell you what you might have wanted to have done. But it is useless 20/20 hindsight. Your GaAs boule has huge ripples and you are wasting lots of money in your process and you start looking for a different solution and you fire those who couldn't understand how to do a proper closed loop control design.

I think I don't know enough about USB to comment here. Yes, I read through much of the over 1000 pages of the USB 2.0 document -- not entirely enjoying it, either. But I seem to recall that the shortest timer on the host side is set at

1ms. And I honestly don't know how that translates into allowable variability -- but I suspect it means a need to plan that much, 1ms, variability. And even then, it might be worse under circumstances I'm not well informed about being as ignorant as I am about USB nuances.

RS-232 isn't "great guns." It's still serial. But with RS-422 for example I can at least get fairly quick transfers of data and at precision intervals that are as known and as predictable as the crystal clocks I'm using to time them. I will usually select a processor with fixed (or very small variability in) latencies relative to timer interrupt events

-- the ADSP-21xx processor for example has zero variability (if it isn't busy with interrupts locked out, of couse) in its interrupting response. These things can be important, at times.

Jon

Reply to
Jon Kirwan

Not to mention variability in managing USB packets and all of the conditional code whose branch edges (different branch pathways) do not all execute in exactly the same number of cycles so that there is a fixed delay which can be planned on. Compilers do NOT provide a method to force fixed timing through all code edges, either.

In the case of simple serial communications, I can much more easily arrange equal timing in all branches of the rather short and simple code, by inspection. So I can guarantee, to the cycle, that there is no variability. Which is good.

Jon

Reply to
Jon Kirwan

USB 2.0 has service intervals down to 125us, isochronous transfers reserve bandwidth slots. With USB 3.0 ("Superspeed"), I think the guaranteed jitter is 200ns, It's higher than that for hi-speed, but I don't remember the value. In most cases it's going to be the software stack that's going to be the limiting factor on jitter. The audio guys seem to be slightly unhappy, apparently wanting 100ns jitter guarantee.

There are certainly advantages to a very lightweight stack.

OTOH, it doesn't sound like you application would really ever make any use of automatic baud rate detection.

Reply to
Robert Wessel

Oh, yeah. I'm on about something different, of course. Just responding to this proposed idea that time-stamping solves all problems.

Jon

Reply to
Jon Kirwan

AVR-based

I have two things to say to you:

Get a copy of the standard and study it, it has been TIA-232 for over 15 years now.

The widget sounds like a great idea, go ahead and make it and sell it, see where it gets you. Be sure to cover all of the off specification implementations out there.

Bye.

?-)

Reply to
josephkk

[...]

Mark,

Apologies for the diversion from your subject, but you have brought up a topic I have been curious about for some time.

Is it easier/cheaper to design and build a through-bulhead connector capable of withstanding (say) 5000psi than (say) an optical or magnetic port through the same bulkhead?

All three approaches can pass data, but only the throug-bulkhead connector can pass power. Is that the major criteria? That is, your application requires more power than can be aeasily be supplied through batteries? Os is there something else involved?

Jes' curious...

Frank

--
  Perhaps the greatest mystery of the Cold War is why the Worker's 
  Paradise could not manage to produce a decent pair of jeans. 
 Click to see the full signature
Reply to
Frnak McKenney

There *are* techniques to wirelessly move power. They're usually either not terribly convenient, or not good for huge amounts of power. For example, you could simply put a large coil of wire on either side, and run AC through one of those, and you've basically got an inefficient transformer. A project I was peripherally associated with many years ago used a pump with no drive shaft (nasty liquids with very exothermic reactions with each other, so leaks were a bad thing). They used a solid aluminum pump housing, with a rotating magnet on the outside, and a matching magnet attached to the impeller inside (think magnetic stirrer). The entire assembly, along with the piping was welded - no seals, shafts, gaskets, joints or anything else to leak. While that didn't move electrical power, replacing the impeller with a small generator would clearly have been possible.

The 5000psi requirement would lead one to guess steel as a primary structural element, which will rather impact your magnetics, so my two examples would be problematic, but here are other approaches.

OTOH, a pair of wires solves all of those problem with rather less complexity (and higher efficiency), except for the need to actually run them through the container wall.

Reply to
Robert Wessel

Optical or magnetic interfaces may work OK at lower pressures, but the mechanical strength to resist 5 to 10KPSI makes the design more difficult. Building an end cap to hold the pressure, but having good data transmission capability can also be expensive. Furthermore, optical and magnetic interfaces may need more power and cost a lot more than an RS-232 interface chip.

Passing power is one criterion. There are systems that can live on internal batteries. We put loggers on moorings on the equator that collect data for 16 channels at up to 100 samples/second. We can use internal lithium primary cells and have enough power to log for a year at about 200MB/day . Those systems only need about 15mA at

7V. Other systems may need 10 or a hundred times that power and collect less data or require external power.

We often use a bulkehead connector in place of a power switch. With a dummy plug, power is off. With a plug routing power through the pins, the system is on. Some instrument makers have tried magnetic reed switches, but you lose the ability to power up the instrument when the batteries diea, and upload data through the port by providing power through the port.

Oceanographic instrument designers envy those doing designs for space: Nothing grows on their instrument surfaces, the medium isn't corrosive, and they only have to worry about pressure differentials of about 1 atmosphere, and asian fishermen don't tie up to satellites because they think it's an easy way to save fuel.

Of course, the space guys do face some other hazards-- micrometeorites, big temperature differentials, etc..

Mark Borgerson

Reply to
Mark Borgerson

It's not so nice in space, either. The following is a paper just on one aspect -- the serious problem of satellite charging effects:

formatting link

Take a look over the long list of satellites and problems.

There are other effects, as well, and a "crud" accumulates over time and covers optics, solar panels, and so on in ways that impair function eventually to the point of failure.

If otherwise lucky, 30 years is about the most you hope for.

Jon

Reply to
Jon Kirwan

Here is another:

formatting link

Jon

Reply to
Jon Kirwan

I must admit that accumulated charge isn't so much a problem for oceanographic instruments. ;-)

I doubt oceanographers would wait that long for their data. It's tough to get high-bandwidth data back in real time from instruments under 30m of seawater. We're recording 2 to 3Kbytes of data per second continuously. Most anything that can transmit with that bandwidth back from the equator exceeds our power budget.

Here's what one of our turbulence sensors looks like after about 6 months to a year on a mooring at the equator:

formatting link

The copper probe at the lower left has the fast-response thermistor that is the primary sensor.

More stuff at:

formatting link

Mark Borgerson

Reply to
Mark Borgerson

Since there are windows on manned vehicles capable of reaching the bottom of the oceans, there should also be other high strength materials for the port hole with suitable dielectric materials to be used with capacitively coupling or near field RF. With a metallic hull, the return current path should be easy to arrange.

Reply to
upsidedown

Those windows are usually at least 8 inches thick. That's a problem for capacitive coupling. Near-field RF is possible, but probably has a larger power budget and higher cost than a pair of connectors and RS-232 transceiver chips.

You don't want to use your pressure case as part of a return path. That's just begging for electrolytic destruction of the pressure case. For shallow pressure cases, we use Delrin plastic. For deeper cases we use aluminum alloys. For the latter, we have to make sure that they are isolated from contact with other metals.

Mark Borgerson

Reply to
Mark Borgerson
[...]

Given the intended application, I tend to agree -- the use of USB would probably simplify the things there a lot.

Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or perhaps even 16-bit) with an on-chip USB. (V-USB doesn't seem to fit well, for its CDC-ACM capability is necessarily a hack.) The best I've found so far are some STM32's for under $4. I'd like to see if there could be anything else at half that price.

(Though USB identifiers may become an issue. They provide one allowing for relatively unrestricted use with V-USB, but I don't know what's the current practice for the MCU's with hardware USB ports.)

--
FSF associate member #7257
Reply to
Ivan Shmakov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.