AVR-Chat

hi,i wanna to use HM-TRS RF transceiver module,but i have a problem with it, i want to send a packet of data to it.
The packet include 5 bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is 4800bps.
i read the data sheet of HM-TRS & attach its address for you.

http://www.hoperf.com/pdf/HM-TRS.pdf

you should know this RF module must accumulate  32 bytes for every sending of data.
but the matter is :

has it at 4800bps continous performance or must accumulate 32 bytes?
second state is unpleasant for me because of my data structure.
this matter at its data sheet has not determined obviously.

> has it at 4800bps continous performance or must accumulate 32 bytes?
> second state is unpleasant for me because of my data structure.
> this matter at its data sheet has not determined obviously.

The data sheet is very poorly written, but it looks like you can send
single bytes, or small numbers of bytes, by waiting at least 30mS.
This is a common approach with packetized transmission protocols.

If you send 32 bytes then the data goes immediately.
If you send 31 bytes or less, then the data goes when the 32nd byte
arrives, OR when 30mS with no additional data elapses.

At least that's what it looks like from reading the data sheet.


-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

the software for exact options

http://www.hoperf.com/tools/HM-TR_SETUP.exe

On Tue, Jul 28, 2009 at 01:13:45PM -0000, iijfet wrote:
> hi,i wanna to use HM-TRS RF transceiver module,but i have a problem
> with it, i want to send a packet of data to it. The packet include 5
> bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is
> 4800bps.
> i read the data sheet of HM-TRS & attach its address for you.
> 
> http://www.hoperf.com/pdf/HM-TRS.pdf
> 
> you should know this RF module must accumulate  32 bytes for every
> sending of data. but the matter is :
> 
> has it at 4800bps continous performance or must accumulate 32 bytes?
> second state is unpleasant for me because of my data structure.
> this matter at its data sheet has not determined obviously.

You should read your own references:
- The module work mode is half duplex mode. The data will be immediately
- transmitted as soon as it accumulates 32 bytes in the serial port.
- When the data is less than 32 bytes, it will transmit again after
- 30ms. If the data is required to be sent out immediately, make sure it
- is at least 32 bytes.

It appears this RF module transmits every 30 mS then spends 5 mS
changing over to receive mode for a period (probably 20 mS) and then
another 5 mS back to transmit mode. So it is very likely there is no way
this RF module can produce the Real Time performance you are expecting.

Is not clear whether this unit transmits 30 mS after the last byte or 30
mS after the first byte of its 32 byte buffer. If after the first then
you will receive two of your 5 byte packets at a time.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
>
> On Tue, Jul 28, 2009 at 07:56:33AM -0700, hossein hashemi wrote:
> > your last paragraph made i read the data sheet again.
> > if data less than 32 bytes exp 25 bytes ,do you think it's transmitted after 30 ms?(pdf is not clear.)
> > it's pleasant for me.
> > 25 bytes as a 5 samples of one patient.but this 30ms,for monitoring, give a discrete state to data,isn't it? but i think i can use the static data for 30ms on monitor.
> > my baud rate is 4800bps.but the data sheet hasn't determined? which baud rate has this problem.? 
> > 
> > 
> > 
> > 
> > --- On Tue, 7/28/09, David Kelly <dkelly@...> wrote:
> > 
> > From: David Kelly <dkelly@...>
> > Subject: Re: [AVR-Chat] RF module
> > To: AVR-Chat@yahoogroups.com
> > Date: Tuesday, July 28, 2009, 6:21 PM
> > 
> > 
> > 
> > 
> > 
> > 
> > ?
> > 
> > 
> > 
> > 
> >     
> >                   On Tue, Jul 28, 2009 at 01:13:45PM -0000, iijfet wrote:
> > 
> > > hi,i wanna to use HM-TRS RF transceiver module,but i have a problem
> > 
> > > with it, i want to send a packet of data to it. The packet include 5
> > 
> > > bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is
> > 
> > > 4800bps.
> > 
> > > i read the data sheet of HM-TRS & attach its address for you.
> > 
> > > 
> > 
> > > http://www.hoperf. com/pdf/HM- TRS.pdf
> > 
> > > 
> > 
> > > you should know this RF module must accumulate  32 bytes for every
> > 
> > > sending of data. but the matter is :
> > 
> > > 
> > 
> > > has it at 4800bps continous performance or must accumulate 32 bytes?
> > 
> > > second state is unpleasant for me because of my data structure.
> > 
> > > this matter at its data sheet has not determined obviously.
> > 
> > 
> > 
> > You should read your own references:
> > 
> > - The module work mode is half duplex mode. The data will be immediately
> > 
> > - transmitted as soon as it accumulates 32 bytes in the serial port.
> > 
> > - When the data is less than 32 bytes, it will transmit again after
> > 
> > - 30ms. If the data is required to be sent out immediately, make sure it
> > 
> > - is at least 32 bytes.
> > 
> > 
> > 
> > It appears this RF module transmits every 30 mS then spends 5 mS
> > 
> > changing over to receive mode for a period (probably 20 mS) and then
> > 
> > another 5 mS back to transmit mode. So it is very likely there is no way
> > 
> > this RF module can produce the Real Time performance you are expecting.
> > 
> > 
> > 
> > Is not clear whether this unit transmits 30 mS after the last byte or 30
> > 
> > mS after the first byte of its 32 byte buffer. If after the first then
> > 
> > you will receive two of your 5 byte packets at a time.
> > 
> > 
> > 
> > -- 
> > 
> > David Kelly N4HHE, dkelly@HiWAAY. net
> > 
> > ============ ========= ========= ========= ========= ========= ========= ======
> > 
> > Whom computers would destroy, they must first drive mad.
> > 
> > 
> >  
> > 
> >       
> > 
> >     
> >     
> > 	
> > 	 
> > 	
> > 	
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 	
> > 
> > 
> > 	
> > 	
> > 
> > 
> >       
> > 
> > [Non-text portions of this message have been removed]
> 
> If you wish to participate in technical forums then you must unlearn bad
> email habits. Top-post without trim is poor manners. Trim all but the
> parts which relate to the contribution in your reply. Add your
> contributions immediately after the parts they relate to. Study the
> format of my previous replies and those of David VanHorn for examples.
> 
> The following is how *this* (my) reply should have been formed:
> 
> On Tue, Jul 28, 2009 at 07:56:33AM -0700, hossein hashemi wrote:
> > your last paragraph made i read the data sheet again. if data less
> > than 32 bytes exp 25 bytes ,do you think it's transmitted after 30
> > ms?(pdf is not clear.)
> 
> Yes, the data sheet is not clear. The module either transmits 30 mS
> after the first byte of data or 30 mS after the last byte of data, it
> does not say.
> 
> > it's pleasant for me.
> > 25 bytes as a 5 samples of one patient.but this 30ms,for monitoring,
> > give a discrete state to data,isn't it?
> 
> Am lost in your grammar.
> 
> Am a bit frightened that you are collecting data from patients.
> 
> You are collecting 5 bytes of data every 16.7 mS. We do not know if the
> module will transmit in the middle of your 3rd 5 byte packet or 7th 5
> byte packet. It will transmit in the middle of the 3rd if it measures 30
> mS from the first byte, or it will transmit in the middle of the 7th
> when the buffer contains 32 bytes if it is waiting for 30 mS of nothing
> before transmitting.
> 
> Either way it can not deliver your data every 16.7 mS, only once every
> 30 mS. Some of your data will have taken longer to arrive than others..
> 
> > but i think i can use the static data for 30ms on monitor. my baud
> > rate is 4800bps.but the data sheet hasn't determined? which baud rate
> > has this problem.? 
> 
> I don't understand "static data".
> 
> The data sheet says the RF module will keep up with constant stream of
> data at 9600 bps. That if you send faster than 9600 you have to slow the
> data, but on closer examination the module has no means of indicating
> that data is being sent too fast.
> 
> -- 
> David Kelly N4HHE, dkelly@...
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>




ok,but i send  email from yahoo not group!i don't repeat again.
your reply is true.i must add a part to codevision for this problem or use another module.

On Tue, Jul 28, 2009 at 09:32:15AM -0400, David VanHorn wrote:
> 
> The data sheet is very poorly written, but it looks like you can send
> single bytes, or small numbers of bytes, by waiting at least 30mS.
> This is a common approach with packetized transmission protocols.
> 
> If you send 32 bytes then the data goes immediately.
> If you send 31 bytes or less, then the data goes when the 32nd byte
> arrives, OR when 30mS with no additional data elapses.

As you said, "poorly written", as it is not clear whether the 30 mS
timer starts with the first byte, or is a watchdog which flushes the
buffer after 30 mS of inactivity.

Either way, I do not believe the original specification of 5 byte
updates 60 times per second can be achieved with this unit.

Says that it can sustain 9600 bps and that it operates half duplex.
Didn't see any mention of master, slave, or peers. 9600 bits/sec is 960
bytes/sec with 1 start 1 stop bit. 32/960 = 33.3 mS which lends me to
believe it will only transmit every 30 mS and that the 60 Hz 16.7 mS
real time specification can never be met.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

> As you said, "poorly written", as it is not clear whether the 30 mS
> timer starts with the first byte, or is a watchdog which flushes the
> buffer after 30 mS of inactivity.

Right.. Sometimes with these products, all you can do is try it and see.
I suspect it is an inactivity timer, but it could just as well be the other one.




-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

your last paragraph made i read the data sheet again.
if data less than 32 bytes exp 25 bytes ,do you think it's transmitted after 30 ms?(pdf is not clear.)
it's pleasant for me.
25 bytes as a 5 samples of one patient.but this 30ms,for monitoring, give a discrete state to data,isn't it? but i think i can use the static data for 30ms on monitor.
my baud rate is 4800bps.but the data sheet hasn't determined  which baud rate has this problem.  




--- On Tue, 7/28/09, David Kelly <dkelly@hiwaay.net> wrote:

From: David Kelly <dkelly@hiwaay.net>
Subject: Re: [AVR-Chat] RF module
To: AVR-Chat@yahoogroups.com
Date: Tuesday, July 28, 2009, 6:21 PM






 




    
                  On Tue, Jul 28, 2009 at 01:13:45PM -0000, iijfet wrote:

> hi,i wanna to use HM-TRS RF transceiver module,but i have a problem

> with it, i want to send a packet of data to it. The packet include 5

> bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is

> 4800bps.

> i read the data sheet of HM-TRS & attach its address for you.

> 

> http://www.hoperf. com/pdf/HM- TRS.pdf

> 

> you should know this RF module must accumulate  32 bytes for every

> sending of data. but the matter is :

> 

> has it at 4800bps continous performance or must accumulate 32 bytes?

> second state is unpleasant for me because of my data structure.

> this matter at its data sheet has not determined obviously.



You should read your own references:

- The module work mode is half duplex mode. The data will be immediately

- transmitted as soon as it accumulates 32 bytes in the serial port.

- When the data is less than 32 bytes, it will transmit again after

- 30ms. If the data is required to be sent out immediately, make sure it

- is at least 32 bytes.



It appears this RF module transmits every 30 mS then spends 5 mS

changing over to receive mode for a period (probably 20 mS) and then

another 5 mS back to transmit mode. So it is very likely there is no way

this RF module can produce the Real Time performance you are expecting.



Is not clear whether this unit transmits 30 mS after the last byte or 30

mS after the first byte of its 32 byte buffer. If after the first then

you will receive two of your 5 byte packets at a time.



-- 

David Kelly N4HHE, dkelly@HiWAAY. net

============ ========= ========= ========= ========= ========= ========= ======

Whom computers would destroy, they must first drive mad.


 

      

    
    
	
	 
	
	








	


	
	


      

[Non-text portions of this message have been removed]

On Tue, Jul 28, 2009 at 10:22:37AM -0400, David VanHorn wrote:
> > As you said, "poorly written", as it is not clear whether the 30 mS
> > timer starts with the first byte, or is a watchdog which flushes the
> > buffer after 30 mS of inactivity.
> 
> Right.. Sometimes with these products, all you can do is try it and
> see. I suspect it is an inactivity timer, but it could just as well be
> the other one.

Then again they say nothing about synchronization between radios. There
may be a window which they always alternate back and forth no matter
whether one has data or not so that each only has one opportunity to
transmit every 30 mS. This results in yet another color to the real time
performance of this radio system.

I successfully used an Aerocomm radio purchased via Mouser.com on a
project. Had a minor problem with my data frame being split between
radio packets. The Visual Basic program on the PC end couldn't handle a
pause in the middle of a data frame. The VB code made no sense to me so
I "fixed" the embedded end. The Aerocomm module had an output pin which
indicated start of RF frame, so I simply wrote my data packets
immediately after being signaled by the radio. In retrospect that is
what I should have been doing in the first place.

Did not have any "real time" requirement above, only requirement was to
get the data from the robot to a disk file. Commands to the robot were
on the reverse channel and only had to be timely as the robot was not
being steered remotely. Basically only speed, direction, start, and stop
were sent.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Tue, Jul 28, 2009 at 07:56:33AM -0700, hossein hashemi wrote:
> your last paragraph made i read the data sheet again.
> if data less than 32 bytes exp 25 bytes ,do you think it's transmitted after 30 ms?(pdf is not clear.)
> it's pleasant for me.
> 25 bytes as a 5 samples of one patient.but this 30ms,for monitoring, give a discrete state to data,isn't it? but i think i can use the static data for 30ms on monitor.
> my baud rate is 4800bps.but the data sheet hasn't determined? which baud rate has this problem.? 
> 
> 
> 
> 
> --- On Tue, 7/28/09, David Kelly <dkelly@hiwaay.net> wrote:
> 
> From: David Kelly <dkelly@hiwaay.net>
> Subject: Re: [AVR-Chat] RF module
> To: AVR-Chat@yahoogroups.com
> Date: Tuesday, July 28, 2009, 6:21 PM
> 
> 
> 
> 
> 
> 
> ?
> 
> 
> 
> 
>     
>                   On Tue, Jul 28, 2009 at 01:13:45PM -0000, iijfet wrote:
> 
> > hi,i wanna to use HM-TRS RF transceiver module,but i have a problem
> 
> > with it, i want to send a packet of data to it. The packet include 5
> 
> > bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is
> 
> > 4800bps.
> 
> > i read the data sheet of HM-TRS & attach its address for you.
> 
> > 
> 
> > http://www.hoperf. com/pdf/HM- TRS.pdf
> 
> > 
> 
> > you should know this RF module must accumulate  32 bytes for every
> 
> > sending of data. but the matter is :
> 
> > 
> 
> > has it at 4800bps continous performance or must accumulate 32 bytes?
> 
> > second state is unpleasant for me because of my data structure.
> 
> > this matter at its data sheet has not determined obviously.
> 
> 
> 
> You should read your own references:
> 
> - The module work mode is half duplex mode. The data will be immediately
> 
> - transmitted as soon as it accumulates 32 bytes in the serial port.
> 
> - When the data is less than 32 bytes, it will transmit again after
> 
> - 30ms. If the data is required to be sent out immediately, make sure it
> 
> - is at least 32 bytes.
> 
> 
> 
> It appears this RF module transmits every 30 mS then spends 5 mS
> 
> changing over to receive mode for a period (probably 20 mS) and then
> 
> another 5 mS back to transmit mode. So it is very likely there is no way
> 
> this RF module can produce the Real Time performance you are expecting.
> 
> 
> 
> Is not clear whether this unit transmits 30 mS after the last byte or 30
> 
> mS after the first byte of its 32 byte buffer. If after the first then
> 
> you will receive two of your 5 byte packets at a time.
> 
> 
> 
> -- 
> 
> David Kelly N4HHE, dkelly@HiWAAY. net
> 
> ============ ========= ========= ========= ========= ========= ========= ======
> 
> Whom computers would destroy, they must first drive mad.
> 
> 
>  
> 
>       
> 
>     
>     
> 	
> 	 
> 	
> 	
> 
> 
> 
> 
> 
> 
> 
> 
> 	
> 
> 
> 	
> 	
> 
> 
>       
> 
> [Non-text portions of this message have been removed]

If you wish to participate in technical forums then you must unlearn bad
email habits. Top-post without trim is poor manners. Trim all but the
parts which relate to the contribution in your reply. Add your
contributions immediately after the parts they relate to. Study the
format of my previous replies and those of David VanHorn for examples.

The following is how *this* (my) reply should have been formed:

On Tue, Jul 28, 2009 at 07:56:33AM -0700, hossein hashemi wrote:
> your last paragraph made i read the data sheet again. if data less
> than 32 bytes exp 25 bytes ,do you think it's transmitted after 30
> ms?(pdf is not clear.)

Yes, the data sheet is not clear. The module either transmits 30 mS
after the first byte of data or 30 mS after the last byte of data, it
does not say.

> it's pleasant for me.
> 25 bytes as a 5 samples of one patient.but this 30ms,for monitoring,
> give a discrete state to data,isn't it?

Am lost in your grammar.

Am a bit frightened that you are collecting data from patients.

You are collecting 5 bytes of data every 16.7 mS. We do not know if the
module will transmit in the middle of your 3rd 5 byte packet or 7th 5
byte packet. It will transmit in the middle of the 3rd if it measures 30
mS from the first byte, or it will transmit in the middle of the 7th
when the buffer contains 32 bytes if it is waiting for 30 mS of nothing
before transmitting.

Either way it can not deliver your data every 16.7 mS, only once every
30 mS. Some of your data will have taken longer to arrive than others..

> but i think i can use the static data for 30ms on monitor. my baud
> rate is 4800bps.but the data sheet hasn't determined? which baud rate
> has this problem.? 

I don't understand "static data".

The data sheet says the RF module will keep up with constant stream of
data at 9600 bps. That if you send faster than 9600 you have to slow the
data, but on closer examination the module has no means of indicating
that data is being sent too fast.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Tue, Jul 28, 2009 at 11:36 AM, iijfet<iijfet@yahoo.com> wrote:
> the software for exact options
>
> http://www.hoperf.com/tools/HM-TR_SETUP.exe

I hope nobody is going to run out and execute that...


-- 
http://itsokjohn.com/

This may be the wrong place to ask, but it's at least related to the last "chat" :-)

I need to make an hi sensitivity/selectivity/stability, low noise tunable RF receiver that can receive around 60MHz (maybe 50-70) and ideally could switch to 10MHz (but the 10MHz requirements are not so stringent).
Worst case, I could separate the 10MHz receiver.

This would be somewhat similar to the requirements of an NMR receiver, if it helps.

Ideally I'd like something that has some first amplifier(s) then some IF stage(s) and then ... I will need IQ demodulation, but that could happen outside of this first chip (I'll also need to digitize the outputs, etc).

Any pointers, please?

Thanks,

Cat


[Non-text portions of this message have been removed]

On Tue, Jul 28, 2009 at 11:04:43AM -0600, Cat C wrote:
> 
> This may be the wrong place to ask, but it's at least related to the last "chat" :-)

The wrongest thing about your request is that you edited a reply to
another thread rather than address a new email to the list.

> I need to make an hi sensitivity/selectivity/stability, low noise
> tunable RF receiver that can receive around 60MHz (maybe 50-70) and
> ideally could switch to 10MHz (but the 10MHz requirements are not so
> stringent). Worst case, I could separate the 10MHz receiver.
> 
> This would be somewhat similar to the requirements of an NMR receiver,
> if it helps.
> 
> Ideally I'd like something that has some first amplifier(s) then some
> IF stage(s) and then ... I will need IQ demodulation, but that could
> happen outside of this first chip (I'll also need to digitize the
> outputs, etc).

Building a good radio is much harder than shopping for the right chip.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

...
> 
> The wrongest thing about your request is that you edited a reply to
> another thread rather than address a new email to the list.
> 
Sorry, I thought I changed the subject line and replaced all the content?



How did you catch me?

...
> 
> Building a good radio is much harder than shopping for the right chip.
> 
> -- 

Anyway, regarding the complexities of "building a good radio"... one needs to start somewhere :-)

Thanks for being so helpful :-)




[Non-text portions of this message have been removed]

Analog devices has some very fast ADC chips for software defined radios.
How much bandwidth do you need?

-- 
http://itsokjohn.com/

I need only about 2KHz bandwidth.
But I need to sample about 1 second, so I'm not sure how that would work.
Also, how I would bring the sub 1uV level to a level that can be digitized?

Thanks,

Cat


> Analog devices has some very fast ADC chips for software defined radios.
> How much bandwidth do you need?
> 



[Non-text portions of this message have been removed]

> Analog devices has some very fast ADC chips for software defined radios.
> How much bandwidth do you need?
>
> --
> http://itsokjohn.com/
>

And what kind of signal (modulation)? There are very few "chips" that fit
these requirements. Most of what is available (as full receivers) is
tightly constrained to FM broadcast band or channelized TV reception.

The real challenge, as previously suggested, is not the selection of an IC
for the receiver. The biggie is the design of filters (antenna to linear
amplifier, linear amplifier to mixer, if, etc). This is for a more or less
conventional superheterodyne receiver. For a direct conversion, antenna to
amplifier to ADC, you have a really big challenge getting the signal
amplified to the level that an ADC can handle AND a challenge with an ADC
that has a high enough sample rate. And, with that sample rate comes a
very high bit-rate data stream. 'Tis not for the faint of heart nor the
"gotta have it now".

There are a number of "scanners" on the market that probably include that
range, but they are rarely characterized as "low noise" or "high
stability". They DO tend to offer a variety of demodulators (but rarely
handle single-sideband (SSB) very well). Many scanners seem to be limited
to a low-end frequency around 50MHz or so, though there ought to be
something lower.

There may be a few general coverage receivers out there. I would check the
HRO (Ham Radio Outlet) website to see what might be available. They should
also have scanners.

Jim Wagner, KA7EHK
Oregon Research Electronics
Tangent, OR, USA

On Tue, Jul 28, 2009 at 11:45:34AM -0600, Cat C wrote:
> 
> ...
> > 
> > The wrongest thing about your request is that you edited a reply to
> > another thread rather than address a new email to the list.
> > 
> Sorry, I thought I changed the subject line and replaced all the content?
> 
> 
> 
> How did you catch me?

Because Reply contains In-Reply-To: and/or References: headers which
link to the Message-ID (and optionally References) of the message you
are replying to.

As a result your message threaded into the wrong place. Those who list
their mailbox in collapsed thread form would not have seen your message
which should have been at the start of a new thread without In-Reply-To
or References headers.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

iijfet wrote:
> hi,i wanna to use HM-TRS RF transceiver module,but i have a problem with it, i want to send a packet of data to it.
> The packet include 5 bytes,& 60 packets come to RF (HM-TRS)per second,my baud rate is 4800bps.
> i read the data sheet of HM-TRS & attach its address for you.
>
> http://www.hoperf.com/pdf/HM-TRS.pdf
>
> you should know this RF module must accumulate  32 bytes for every sending of data.
> but the matter is :
>
> has it at 4800bps continous performance or must accumulate 32 bytes?
> second state is unpleasant for me because of my data structure.
> this matter at its data sheet has not determined obviously.
>   
Just for reference, you might want to check the wireless offerings at 
Sparkfun http://www.sparkfun.com/
They have stuff from FM band up to 2.4 GHz including a number of XBee 
and Nordic nRF2401 modules.

Bruce

> There may be a few general coverage receivers out there. I would check the
> HRO (Ham Radio Outlet) website to see what might be available. They should
> also have scanners.

I like my RC-8500.. :)  Pretty much "DC to Daylight".  No bands, all modes.
A real pity they didn't do a companion transmitter.

-- 
http://itsokjohn.com/

On Tue, Jul 28, 2009 at 2:22 PM, Cat C<catalin_cluj@hotmail.com> wrote:
>
> I need only about 2KHz bandwidth.
> But I need to sample about 1 second, so I'm not sure how that would work.
> Also, how I would bring the sub 1uV level to a level that can be digitized?

Sounds like you could take the output of a receiver like the IC-R8500
and feed the audio into an ADC.
The AVR one might be up to this task, depending on how finely you need
that sampled.

The usual approach with narrowband receivers is to filter, amplify,
mix, filter, and amplify (single conversion superhet)


-- 
http://itsokjohn.com/

----- Original Message ----- 

From: "David VanHorn" <microbrix@gmail.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Wednesday, July 29, 2009 4:16 PM
Subject: Re: [AVR-Chat] Looking for RF Receiver IC


> On Tue, Jul 28, 2009 at 2:22 PM, Cat C<catalin_cluj@hotmail.com> wrote:
>>
>> I need only about 2KHz bandwidth.
>> But I need to sample about 1 second, so I'm not sure how that would work.
>> Also, how I would bring the sub 1uV level to a level that can be 
>> digitized?
>
> Sounds like you could take the output of a receiver like the IC-R8500
> and feed the audio into an ADC.
> The AVR one might be up to this task, depending on how finely you need
> that sampled.
>
> The usual approach with narrowband receivers is to filter, amplify,
> mix, filter, and amplify (single conversion superhet)

and demodulate. 8-)

Leon

Yes, I'm still trying to define which way we'll go so that's why I wanted to 
see what chips are available in case there is something that will get me 
close.

Regarding sampling at RF, it looks like undersampling is an option that 
works but I don't quite understand all the implications... looks interesting 
though.  Of course, if I bring the level up first.

The bandwidth is only about 1KHz, but the level will be 1uV and below.
I can't use a ready made scanner, but maybe some chips "they" use in 
scanners.
One problem is most chips are for higher frequencies now...

Thank you,

Cat

> And what kind of signal (modulation)? There are very few "chips" that fit
> these requirements. Most of what is available (as full receivers) is
> tightly constrained to FM broadcast band or channelized TV reception.
> The real challenge, as previously suggested, is not the selection of an IC
> for the receiver. The biggie is the design of filters (antenna to linear
> amplifier, linear amplifier to mixer, if, etc). This is for a more or less
> conventional superheterodyne receiver. For a direct conversion, antenna to
> amplifier to ADC, you have a really big challenge getting the signal
> amplified to the level that an ADC can handle AND a challenge with an ADC
> that has a high enough sample rate. And, with that sample rate comes a
> very high bit-rate data stream. 'Tis not for the faint of heart nor the
> "gotta have it now".
>
> There are a number of "scanners" on the market that probably include that
> range, but they are rarely characterized as "low noise" or "high
> stability". They DO tend to offer a variety of demodulators (but rarely
> handle single-sideband (SSB) very well). Many scanners seem to be limited
> to a low-end frequency around 50MHz or so, though there ought to be
> something lower.
>
> There may be a few general coverage receivers out there. I would check the
> HRO (Ham Radio Outlet) website to see what might be available. They should
> also have scanners.
>
> Jim Wagner, KA7EHK
> Oregon Research Electronics
> Tangent, OR, USA

Thank you, I'll try to do it right next time.

Cat

--------------------------------------------------

From: "David Kelly" <dkelly@hiwaay.net>
Sent: Tuesday, July 28, 2009 2:32 PM
To: <AVR-Chat@yahoogroups.com>
Subject: Re: [AVR-Chat] Looking for RF Receiver IC

> On Tue, Jul 28, 2009 at 11:45:34AM -0600, Cat C wrote:
>>
>> ...
>> >
>> > The wrongest thing about your request is that you edited a reply to
>> > another thread rather than address a new email to the list.
>> >
>> Sorry, I thought I changed the subject line and replaced all the content?
>>
>>
>>
>> How did you catch me?
>
> Because Reply contains In-Reply-To: and/or References: headers which
> link to the Message-ID (and optionally References) of the message you
> are replying to.
>
> As a result your message threaded into the wrong place. Those who list
> their mailbox in collapsed thread form would not have seen your message
> which should have been at the start of a new thread without In-Reply-To
> or References headers.
>
> -- 
> David Kelly N4HHE, dkelly@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>