Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Encoder/Decoder IC's......

Status
Not open for further replies.

Mr CCE

New Member
Hi everyone,

I'd like to ask about the codec IC's 145026/7, it is mensioned in the datasheets that the encoder has five address inputs/pins and four data pins, so if I'm sending a byte for PIC to PIC communication, how is that done?

thx
 
Last edited:
Right Nigel, it encodes a few switch inputs to some signal it sends over the air and then decodes it to like signals on the other... It's an encoder/decoder, whos use happens to be remote control. It being a remote control doesn't preclude it from being an encoder/decoder pair so I'm not sure exactly where your logic is coming from. That's like saying a car doesn't have wheels because it's a car.
 
Last edited:
Right Nigel, it encodes a few switch inputs to some signal it sends over the air and then decodes it to like signals on the other... It's an encoder/decoder, whos use happens to be remote control. It being a remote control doesn't preclude it from being an encoder/decoder pair so I'm not sure exactly where your logic is coming from. That's like saying a car doesn't have wheels because it's a car.

The logic is that it's not what the OP was wanting - he's been confused by the misleading description on the datasheet - he's wanting an encoder to send data over a radio link, not a crude remote control.

To build on from your simile, it's like you're wanting a truck to move 20 tonnes of gravel, but you buy a moped instead - they are both transport with wheels, but for entirely different purposes.
 
Well............

Hi there,

Well it doesn't really matter wether it's a remote control or a codec pair! All I want is to securely send data over a radio link and receive it properly on the Rx side with minimun/no error, and that's what these two chips are giving me.

Relax guys!;)

keep up the good work!!

regards.
 
Last edited:
Nigel, that crude remote control can be used to send low speed data... Depends on Mr CCE's data requirements.
 
Yes, but it's crude, nasty. limited, VERY slow, and requires much more programming to use - if you're going to add external encoders/decoders why not use a proper one?. In this case he's used the completely wrong chip, simply because it's confusingly named by the manufacturer.
 
Because that's what he has? I run across that kind of situation frequently. I have many components that aren't ideal but will work in a practical fashion because I cannibalize almost all of my components rather than buying stuff new
And no offense to Mr CCE, but it's not the company that's at fault, Mr CCE didn't understand what he was buying or what else might be available. It's serviceable for his needs if his needs are minimal. Assuming such a chip will provide minimal/low error rates is however a horrible idea. You have to have software to back up the hardware or it'll never be reliable. No RF link can EVER be completely reliable.
 
Fair enough...

Hey everyone,

And no offense to Mr CCE, but it's not the company that's at fault, Mr CCE didn't understand what he was buying or what else might be available. It's serviceable for his needs if his needs are minimal. Assuming such a chip will provide minimal/low error rates is however a horrible idea. You have to have software to back up the hardware or it'll never be reliable. No RF link can EVER be completely reliable.

No offense taken friend, but the thing is, I didn't just go out and start asking about what I need for my situation, the person who recommended these codec pairs (and I insist on using the word "codec") is someone who didn't start working with electronics/mcu's/digital communication just yesterday, but has been doing so for years, his experience and his very successful company are there to prove it.

Moreover, software backup is there; the mcu program contains a subroutine that will ensure the placement of each and every bit of whatever I'm sending into it's rightful place in the data stream, so rest assured 'cause it's doing its job very efficiently so far.

I agree that no RF link can be completely reliable, but then again, how are we using wireless devices? wifi access points, cellular phones, etc .....
In my opinion, and according to my 'very humble' experience in the field, if you have the proper equipment-however costly it may be- and some decent algorithms 'software-wise', you could end up with a really good RF link that's enough to get the job done, whatever you're doing.

keep up the good work gentlemen!!

regards.
 
No offense taken friend, but the thing is, I didn't just go out and start asking about what I need for my situation, the person who recommended these codec pairs (and I insist on using the word "codec") is someone who didn't start working with electronics/mcu's/digital communication just yesterday, but has been doing so for years, his experience and his very successful company are there to prove it.

Sorry, but if your friend recommended you use those unsuitable devices, he obviously doesn't have a clue - I suspect he simply read the title on their datasheet, and never looked what they actually were.
 
Huh?!?...

Sorry, but if your friend recommended you use those unsuitable devices, he obviously doesn't have a clue - I suspect he simply read the title on their datasheet, and never looked what they actually were.

You know what, .. ah forget it. No comment.
 
Nigel, I'm gonna have to go with Mr CCE, as long as the frequency he's feeding those remote control lines is substantially less than the overall frequency window it'd be easier to interface to than some more purpose built RF modules, he's got access to an entire nibbles worth of data at one go. Considering what they are it was probably an order of magnitude cheaper than a 'proper' RF module and likley work as well for his needs.

As far as reliability goes Mr CCE the only thing I'm warning you against is ever using an RF link on a device who's communication loss could result in harm to another person or damage to equipment, as at some point you will have an unexpected drop in signal for some reason. That being said if it still works for your purposes, then great. The address registers actually take some of the software side of thing out of the equation if you're talking to multiple devices, and provides a crude form of error checking, as any error in the address byte that it sends will result in the receiver not getting the data. It has a bit more overhead than a more general purpose RF link IC might but should work in many small projects.
 
Nigel, I'm gonna have to go with Mr CCE, as long as the frequency he's feeding those remote control lines is substantially less than the overall frequency window it'd be easier to interface to than some more purpose built RF modules, he's got access to an entire nibbles worth of data at one go.

As opposed to an entire BYTE in one go by using the correct chips - I fail to see the reasoning behind promoting using the completely wrong device, which is MUCH more complicated to use, MUCH slower, and almost certainly MUCH less reliable. Refer to post #2 where I linked to one example of a suitable device.
 
Nigel, because said 'remote control' IC probably costs a few dimes. The only refrence I was able to find for the module you linked was 12 dollars each!
Why are you arguing this so steadfastly? If it works in his application which he's stated thus far that it does then you're just straight up wrong I'm sorry. How are you so sure you know a 'suitable device' when you don't even know his data requirements are in the first place?

Mr CCE wasn't looking for a lecture or the best possible components to use in an RF link, he was looking for how to use what he had in his application, yet you're hounding him to the ends of the earth over the use of a particular chip in an application that you know NOTHING about! He only came here asking for interfacing advice.

You being a moderator who has deleted posts of mine for giving people less grief than this I find it more than a little confusing about your nearly dogged determination to shoot down someone trying to find a successful way to use what he already has in a positive way...
 
Last edited:
Nigel, because said 'remote control' IC probably costs a few dimes. The only refrence I was able to find for the module you linked was 12 dollars each!

Perhaps you should have looked at the encoder/decoder IC price?, and not for one built-in a radio module (as he already had the radio modules).

Why are you arguing this so steadfastly? If it works in his application which he's stated thus far that it does then you're just straight up wrong I'm sorry. How are you so sure you know a 'suitable device' when you don't even know his data requirements are in the first place?

I've no problem with it 'working', even though it's a horrible bodge - and I'm fully aware of his data requirements, and he's very crudely stitching two nibbles together to make his required byte.

Mr CCE wasn't looking for a lecture or the best possible components to use in an RF link, he was looking for how to use what he had in his application, yet you're hounding him to the ends of the earth over the use of a particular chip in an application that you know NOTHING about! He only came here asking for interfacing advice.

Like I said, I'm fully aware of his requirements - and he didn't 'use a chip he had', he went out and bought the wrong chips after been given poor advice.

There have been many posts in these forums about similar wrong choice of chips, usually with people attempting to make the Holtek remote control chips work as data transfer - this is probably the first (that I'm aware of) where incorrect Motorola chips were used.
 
In that case I'd say this thread needs to be immediately locked and Nigel and Mr CCE can go into a private conversation because all the information to properly take part in this thread isn't present in it, because there is no mention of ANY of what you just said previous to this post.

Mr CCE if what Nigel says is correct and you already have a separate RF module that you're trying to interface with then you need to immediately get rid of that remote control IC and take a look at Nigels PIC code for interfacing with an RF module. He's DONE this before, so ignoring what he has to say is folly. The encoding and decoding of the RF signal itself can be done completely on the pic with the right software, no external encoder/decoder are needed.

Sorry for getting on your case Nigel, not all the information needed to respond is in this thread.
 
Last edited:
No apology required - but threads here are an historical record, and while the OP may be happy with his 'one off' bodge, it's not something you want to leave uncommented on for future constructors to go the same way.

I was suggesting the hardware Manchester chips because the OP was using a HLL, and not assembler, so suggesting my assembler Manchester routines didn't seem appropriate.
 
The past posts are saved but this is a new thread, you can't expect someone to know a previous post history on a discussion they didn't take part in, a simple link to the other thread(s) would have done wonders =)
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top