Batteries & Chargers

[AtomSoft]

Wow nigel i though i would get lost with Manchester scheme but it is pretty straight forward.

Nice tutorial. Ill be sure to print it and use as a reference. I hope if i should fall into some trouble you will be around to help

 

[ericgibbs]

Wow nigel i though i would get lost with Manchester scheme but it is pretty straight forward.

Nice tutorial. Ill be sure to print it and use as a reference. I hope if i should fall into some trouble you will be around to help

hi atom

I have used standard ASCII in RS232 data transmission in telemetry for years with no problems.

However you must make your own mind up.

 

[Nigel Goodwin]

I have used standard ASCII in RS232 data transmission in telemetry for years with no problems.

So what happens when the receiver is out of range, or the transmitter is turned off - and if you're using the hardware UART (without hardware inversion) what happens during a lull in data transmisison? (as wireless links aren't DC coupled).

Are you perhaps using radio links with encoder/decoder built-in?, or ones with modems built-in.

 

[AtomSoft]

I need more info on both. Manchester coding seems easy but i dont like the fact that i have to send "52 bits to send just a single 8 bit data byte" I feel like it asking too much that way. Even tho its more stable still...

If i use UART (ASCII) can i still use that parity bit thing? I never really learned about it. And also like 1 stop bit. You know what i mean?

 

[ericgibbs]

I need more info on both. Manchester coding seems easy but i dont like the fact that i have to send "52 bits to send just a single 8 bit data byte" I feel like it asking too much that way. Even tho its more stable still...

If i use UART (ASCII) can i still use that parity bit thing? I never really learned about it. And also like 1 stop bit. You know what i mean?

hi,
You can use parity and the required stop bits.

 

[ericgibbs]

So what happens when the receiver is out of range, or the transmitter is turned off - and if you're using the hardware UART (without hardware inversion) what happens during a lull in data transmisison? (as wireless links aren't DC coupled).

Are you perhaps using radio links with encoder/decoder built-in?, or ones with modems built-in.

hi,
During normal operation of the link, the RX often loses the carrier, also in certain applications the transmitter is switched off to conserve power while collecting data and powered up to transmit.

The hardware inversion, providing its the same at both ends has no bearing on the problem.

I know telemetry links arent dc coupled I have been using them on a daily basis since the early 1980's, to transmit/receive ascii data, with no problems.

It obvious as I am talking about systems with inbuilt encoders/decoders how else would they work as RS232 data links.? The carrier has to be modulated/demodulated.

Perhaps you should look at the Magenta Radio and Wood and Douglas telemetry system datasheets

Attached a clip from the sparkfun tX data.

EDIT: added this tutorial link for sparkfun
https://www.electro-tech-online.com/custompdfs/2008/08/KLP_Walkthrough.pdf

 

[Nigel Goodwin]

hi,
During normal operation of the link, the RX often loses the carrier, also in certain applications the transmitter is switched off to conserve power while collecting data and powered up to transmit.

So what happens to your received data when that happens, doesn't it just become random rubbish?.

The hardware inversion, providing its the same at both ends has no bearing on the problem.

It's got a great bearing, because unless you hardware invert (at both ends) the default state of the UART output is HIGH this is essentially trying to transmit a DC level, and the wireless link is AC coupled. After a number of mS the HIGH output on the receiver drops low in a very noisey fashion, genertaing yet more random values.

By hardware inverting, the default state is LOW, and you don't get that particular problem.

I know telemetry links arent dc coupled I have been using them on a daily basis since the early 1980's, to transmit/receive ascii data, with no problems.

It obvious as I am talking about systems with inbuilt encoders/decoders how else would they work as RS232 data links.? The carrier has to be modulated/demodulated.

Encoded and modulated are entirely different things, encoded ones have processors on board, to convert to and from Manchester packets, allowing simple RS232 connections. The modulation is normally just simple amplitude (ON/OFF) or FSK on FM.

Perhaps you should look at the Magenta Radio and Wood and Douglas telemetry system datasheets

Attached a clip from the sparkfun tX data.

EDIT: added this tutorial link for sparkfun
https://www.electro-tech-online.com/custompdfs/2008/08/KLP_Walkthrough-1.pdf

They look like normal simple plain none encoded ones?.

Are they AM ones?, if they use simple ON/OFF modulation, that may well take care of the hardware inversion problem?.

 

[ericgibbs]

hi Nigel,

I am talking of actual systems that work in the manner I have described.

If you lived closer to me I would take you out for day and show you these systems working.

Read the tutorial that sparkfun have produced regarding the direct connection to a PIC's uart it can't be any plainer than that.

 

[Nigel Goodwin]

hi Nigel,

I am talking of actual systems that work in the manner I have described.

If you lived closer to me I would take you out for day and show you these systems working.

You didn't answer my question though about what happens when the transmitter drops out of range or goes too weak, do you get random rubbish out of the receiver?. If not, why not?

Read the tutorial that sparkfun have produced regarding the direct connection to a PIC's uart it can't be any plainer than that.

Depends how reliable you want it?

 

[ericgibbs]

You didn't answer my question though about what happens when the transmitter drops out of range or goes too weak, do you get random rubbish out of the receiver?. If not, why not?
Depends how reliable you want it?

ALL incoming data is verified by the MCU program and if its not valid, its dumped, its standard practice, I thought you would have known, thats why I didnt bother to reply on that point.

As you dont seem to be aware, the same data corruption can occur due to pick up from 'other foreign' transmitters operating close by, thats why ALL telemetry data is verified at the RX by the MCU before being used.

Also TX/RX using Man coding can suffer from this type of corruption, are you saying those MCU's dont valid their data.?

As I said I am talking about practical systems that have been operating for years.

 

[Nigel Goodwin]

ALL incoming data is verified by the MCU program and if its not valid, its dumped, its standard practice, I thought you would have known, thats why I didnt bother to reply on that point.

But preventing it even happening is a better solution.

As you dont seem to be aware, the same data corruption can occur due to pick up from 'other foreign' transmitters operating close by, thats why ALL telemetry data is verified at the RX by the MCU before being used.

Again, Manchester coding is more robust under those circumstances as well, pretty well all commercial equipment uses it, or something similar.

Also TX/RX using Man coding can suffer from this type of corruption, are you saying those MCU's dont valid their data.?

Manchester is usually used as a packet system, and obviously uses validation of various types - it depends how many bytes per packet you want to use.

 

[ericgibbs]

Again, Manchester coding is more robust under those circumstances as well, pretty well all commercial equipment uses it, or something similar.

Pretty well ALL telemetry is not MAN coding, it mabe more robust than some of the simplier systems I cant deny, but it also suffers from data corruption, which must be catered for in the program.

But preventing it even happening is a better solution.

Prevention is always better than a cure, but MAN dosnt give you total prevention. Thats why the program has to take care of invalid data.

Manchester is usually used as a packet system, and obviously uses validation of various types - it depends how many bytes per packet you want to use.

Dont dispute that.

Nigel,
Not wishing to be a bore, but I have used radio data links in my Hydrographic and Land surveying products, for over 20 years, and I have literally hundreds of systems working world wide.

May I ask, what practical usage experience have you had in this field.?

 

[Nigel Goodwin]

May I ask, what practical usage experience have you had in this field.?

Only in using them, and using products which use them - most of which use Manchester coding or similar.

I can only imagine you've only ever used AM units?, and not FM ones, because the way you're using them wouldn't work with FM ones, and suffers from greater problems even with AM ones.

 

[ericgibbs]

Only in using them, and using products which use them - most of which use Manchester coding or similar.

I can only imagine you've only ever used AM units?, and not FM ones, because the way you're using them wouldn't work with FM ones, and suffers from greater problems even with AM ones.

Isnt it always the same; the ones we use the most become our preferred choice.

As I am sure we both agree, there are applications where one method is better than the other.
Quite often in commercial projects the buyer dictates the direction we take, after all he's the guy who's getting the invoice.!

I suppose we should stop hijacking 'atomsoft's thread.

 

[AtomSoft]

lol im actually enjoying this. You both are good points. I still would prefer to try out the uart since i have some experience with it.

 

[ericgibbs]

lol im actually enjoying this. You both are good points. I still would prefer to try out the uart since i have some experience with it.

hi atom,
Thats the beauty of PIC's you can trial both methods by a simple program change.
Let us know which you find the best for your application

Not trying to influence you, but the cheques in post.

Are you going to buy a 7V5 NiMH charger or build your own.?

 

[AtomSoft]

not sure yet. Building one seems trivial.

Tell me if im wrong...
To charge the batteries i have to just supply a certain voltage @ a certain current and it should charge ok?

Of course i would measure the temperature and turn off when too hot.

 

[audioguru]

Energizer says that their Ni-MH cells should have a circuit (like a battery charger IC) that detects the voltage peak that occurs when the cells are fully charged then switches off the charger or reduces the current to C/40. The 2500mah aA cells would have a trickle charge current of 2500/40= 62.5mA. They recommend that a temperature sensor and a timer be used as a backup circuits to disconnect the charger.

A 7.2V battery will be at about 9V when it is fully charged.

 

[ericgibbs]

not sure yet. Building one seems trivial.

Tell me if im wrong...
To charge the batteries i have to just supply a certain voltage @ a certain current and it should charge ok?
Of course i would measure the temperature and turn off when too hot.

hi atom,
In line with 'agu' you need a smart charger.
Goto the Oshonsoft website,, under Projects there are two open source smart chargers using a PIC. They can be modified for 5 cells.

Ideally I would build a 1C charger and use the deltaV method for controlling the end charge time.

 

[AtomSoft]

Cool! I will surely try this out... Thanks! I just need to buy some parts. (mainly the transistors) I never used the BC5xx series. Also those large resistors. I have some 2x16 lcds to spare and a prefboard. Ill give it a shot!

Oh but i dont get paid till Saturday so theres a delay! lol