Searching \ for '[EE]:Telemetry encoding' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=telemetry+encoding
Search entire site for: 'Telemetry encoding'.

Exact match. Not showing close matches.
PICList Thread
'[EE]:Telemetry encoding'
2000\06\14@161620 by Andrew Seddon

picon face
I am actually doing this at the minute but with a radiometrix data module.
Try taking a look at their site, http://www.radiometrix.com for some info. It has
stuff on the type of packets, serial format etc, most will be relevent for
the Linx module. Once I have some code ready I will put it on the list but I
have hardly started it yet.

{Original Message removed}

2000\06\14@162906 by Dr. Chris Kirtley

flavicon
face
Dear Andrew,

Great - thanks! I haven't actually started my PIC circuit yet. I have
still to decide on which PIC to go for. I wonder if that is a
consideration as far as the telemetry goes. For example - should I chose
a PIC with USART? I was going to use a PIC16C710 but I don't think it
has one, has it?

Size is important for me, so I don't want to use a PIC with more pins
than I need (e.g. PIC16F873, with USART, has 28 pins).

I'd hate to design my circuit around one PIC only to discover later that
another one would have been better!

Chris
--
Dr. Chris Kirtley MD PhD
Associate Professor
HomeCare Technologies for the 21st Century (Whitaker Foundation)
NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation
Dept. of Biomedical Engineering, Pangborn 105B
Catholic University of America
620 Michigan Ave NE
Washington, DC 20064
Tel. 202-319-6247,  fax 202-319-4287
Email: spam_OUTkirtleyTakeThisOuTspamcua.edu
http://engineering.cua.edu/biomedical

Clinical Gait Analysis: http://guardian.curtin.edu.au/cga
Send subscribe/unsubscribe to .....listprocKILLspamspam@spam@info.curtin.edu.au

2000\06\14@170022 by Dan Michaels

flavicon
face
Chris Kirtley wrote:
>
>Great - thanks! I haven't actually started my PIC circuit yet. I have
>still to decide on which PIC to go for. I wonder if that is a
>consideration as far as the telemetry goes. For example - should I chose
>a PIC with USART? I was going to use a PIC16C710 but I don't think it
>has one, has it?
>
>Size is important for me, so I don't want to use a PIC with more pins
>than I need (e.g. PIC16F873, with USART, has 28 pins).
>
>I'd hate to design my circuit around one PIC only to discover later that
>another one would have been better!
>

Chris,

Having used all the basic package sizes of 2nd gen PICs, 8-40
pins, I would definitely recommend the 28-pin - '73 - for general
use. It's not much larger than the 18-pin, but it is *much* smaller
than the 40. Also, the '73/'873 have **SOOOOOO** much more built-in
capablility than the 18-pin guys - more EPROM & RAM, UART/I2C/SPI,
extra timers and A/D channels, etc/etc. Plus, before you know it,
you'll really need those extra I/O pins. You will not be sorry.

best regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\06\14@180308 by Jilles Oldenbeuving

flavicon
face
Actually, i'm busy with it too right now! (Let's start a Telemetry encoding
list <g>)
Only, i'm decideing at the moment wich radio module to use... I've got some
parts from Quasar (http://www.quasar-ltd.com) and RF Solutions. Didn't buy any
Radiometrix modules, becouse the price is to high for my mid-quantity
application.
Anybody has some good suggestions on what to use?

I've also looked at the radiometrix site at that info you're talking about.
What scheme will
you be useing for the telemtry encodeing? (or what scheme's have others
used with succes?)  I think one also has to implement a CRC-check. For my
testing purposes i'd thought about the summing-check (just sum all the data
you want to send, without respect to the carry bit). But after diving into
the
matter more closely i'd say one has to use a real CRC-check (dividing the
data with a "poly", or whatever). I'm not sure how i could treat the 6
databytes
i want to send as a long series of bits wich will be devided by the poly in
an
effecient way.....



{Quote hidden}

Chris: I would use one pic of wich you would surely know that it could
housefest all your needs. When it is fully functional, you could port it
to a smaller pic. That shouldn't be a problem (don't use USART's that
way...etc.). Or you must make up for yourself what you will be needing
in your app. (always a really good thing :)


Regards,

Jilles Oldenbeuving
jillesspamKILLspamrendo.dekooi.nl

2000\06\14@185929 by Dr. Chris Kirtley

flavicon
face
Dear Jilles,

The RF modules I have are from Linx, and seem very good. They are 13 x
9.5 x 3.8 mm in size and have a range of 300 feet (with suitable
antenna, of course). TXM-418-LC is the one I bought. You have to buy the
development kit first order ($200 including 2 transmitters and 2
receivers).

http://www.linxtechnologies.com/main.html

Chris
--
Dr. Chris Kirtley MD PhD
Associate Professor
HomeCare Technologies for the 21st Century (Whitaker Foundation)
NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation
Dept. of Biomedical Engineering, Pangborn 105B
Catholic University of America
620 Michigan Ave NE
Washington, DC 20064
Tel. 202-319-6247,  fax 202-319-4287
Email: .....kirtleyKILLspamspam.....cua.edu
http://engineering.cua.edu/biomedical

Clinical Gait Analysis: http://guardian.curtin.edu.au/cga
Send subscribe/unsubscribe to EraseMElistprocspam_OUTspamTakeThisOuTinfo.curtin.edu.au

2000\06\15@074258 by Andrew Seddon

picon face
> Chris Kirtley wrote:
> >
> >Great - thanks! I haven't actually started my PIC circuit yet. I have
> >still to decide on which PIC to go for. I wonder if that is a
> >consideration as far as the telemetry goes. For example - should I chose
> >a PIC with USART? I was going to use a PIC16C710 but I don't think it
> >has one, has it?
> >
> >Size is important for me, so I don't want to use a PIC with more pins
> >than I need (e.g. PIC16F873, with USART, has 28 pins).
> >
> >I'd hate to design my circuit around one PIC only to discover later that
> >another one would have been better!
> >
>

It shouldn`t really matter too much as you could bit bang the serial port at
slow telemetry rates on pretty much anything. You do however have the extra
hassle of writing the code. For small runs I would stick with the larger
chip with the USART.

I would however recommend that you use the slowest crystal you can to avoid
interference. I am using 50mhz on mine and I am going to have to fit a lot
of extra shielding as interference is proving to be a problem .

Hope that helps.

2000\06\15@074913 by Andrew Seddon

picon face
----- Original Message -----
From: Jilles Oldenbeuving <jillesspamspam_OUTRENDO.DEKOOI.NL>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Wednesday, June 14, 2000 11:03 PM
Subject: Re: [EE]:Telemetry encoding


> Actually, i'm busy with it too right now! (Let's start a Telemetry
encoding
> list <g>)
> Only, i'm decideing at the moment wich radio module to use... I've got
some
> parts from Quasar (http://www.quasar-ltd.com) and RF Solutions. Didn't buy any
> Radiometrix modules, becouse the price is to high for my mid-quantity
> application.
> Anybody has some good suggestions on what to use?
>
> I've also looked at the radiometrix site at that info you're talking
about.
> What scheme will
> you be useing for the telemtry encodeing? (or what scheme's have others
> used with succes?)  I think one also has to implement a CRC-check. For my
> testing purposes i'd thought about the summing-check (just sum all the
data
> you want to send, without respect to the carry bit). But after diving into
> the
> matter more closely i'd say one has to use a real CRC-check (dividing the
> data with a "poly", or whatever). I'm not sure how i could treat the 6
> databytes
> i want to send as a long series of bits wich will be devided by the poly
in
> an
> effecient way.....
>
>

I`m not sure about the modules that you are using but the radiometrix ones
work best on a 50:50 mark space ratio. I think you would probably get better
data rates if your error checking scheme tried to maintain this.. Possibly
using a parity bit to make each byte 50:50?? Not really sure, when I have
sorted mine I will post some code.

2000\06\15@082039 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

A single parity bit (per byte) won't help you acheive a balanced 1/0 ratio.
Probably the most simple method is to use Manchester encoding where each bit
is sent as a 0/1 or 1/0 transistion, ensuring a balanced bit stream.  This
does of course use twice the bandwidth of simple NRZ encoding.  Another way
is make the system packet based, and have your packet controller pad out the
packets to ensure a balanced bit stream.  How large/small the packets can be
made depends on the bit rate and the maximum 1 or 0 time that the radio
system can reliably transmit/receive.  I believe Radiometric actually sell a
packet controller which takes care of all this.

Mike

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...