<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: PIC, SPI and the RFM12</title>
	<atom:link href="http://blog.strobotics.com.au/2007/11/26/pic-spi-and-the-rfm12/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.strobotics.com.au/2007/11/26/pic-spi-and-the-rfm12/</link>
	<description>Where Photographer and Geek merge......</description>
	<lastBuildDate>Sun, 18 Dec 2011 11:07:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Stephen Eaton</title>
		<link>http://blog.strobotics.com.au/2007/11/26/pic-spi-and-the-rfm12/comment-page-1/#comment-315</link>
		<dc:creator>Stephen Eaton</dc:creator>
		<pubDate>Thu, 27 Mar 2008 00:44:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingrobotics.com/2007/11/26/pic-spi-and-the-rfm12/#comment-315</guid>
		<description>Hi, 

It might be best to move this to the forums (http://forums.everythingrobotics.com/ )as I&#039;ve set up a topic dedicated for the RFM12 as I have been getting a few questions.

When you say the receiver status are you sending a status command, 0x0000, and reading the result?

I have working code in SVN located here: http://svn.everythingrobotics.com/strobist/mk1/trunk/arch/pic16f88-boostc/src/

The test_rfm code sends out a string of data on the TX and the Rx receives and lights up led if all good.  Code is fairly well documented and the RFM12 library works in polled mode, will also give you base configs to get started, although its the 915MHZ band it should work on 433MHZ

A couple of things to check:

1) Before you turn the receiver on are you resetting the FIFO?

2) If you are using SPI to read data from RFM then make sure you set the fifo to interrupt on 8 bits, that way when you read a status on the reciever the first bit is the receiver interrupt, if this is a 1 then a valid character has been received and then you can read it via the FIFO read command.

3) When transmitting make sure that when you send out your packet make sure preamble is min of 3 bytes then sync code then your data.  Also make sure that there is no interruption or pause in the process, if there is then receiver will loose sync after certian time and you need to repeat the sync process.

4) When transmitting are you checking the status of the TX register interrupt?  it is the first bit of the 0x0000 status when in Tx mode.  Only when it is 1 can you write the next byte to the Tx register.  What I do is write the first two bytes into the Tx register, turn on the Tx then monitor the status bit, write the next byte and so on then when I&#039;ve transmitted my complete packet I then write a couple of preamble bytes to the Tx register and turn off the TX. so that way the Tx register is flushed before I turn off the TX

5) make sure when turing on Tx or Rx that you allow for timing for tx/Rx to settle before transmitting.  These are in the spec sheet as I can&#039;t remember off hand what they are.  i.e. if you are turning on the whole Tx/Rx chain then it takes longer to stabalize than say having the oscillators etc are already enabled and all you are doing is enabling the PLL etc then it&#039;s a very short turn around time.

6) As its in unlicensed band there will be interference around, try changing frequencies.

7) Start with a datarate of 9600bps to get it all working then change speed to the required datarate once you are getting successful Tx and RX.</description>
		<content:encoded><![CDATA[<p>Hi, </p>
<p>It might be best to move this to the forums (<a href="http://forums.everythingrobotics.com/" rel="nofollow">http://forums.everythingrobotics.com/</a> )as I&#8217;ve set up a topic dedicated for the RFM12 as I have been getting a few questions.</p>
<p>When you say the receiver status are you sending a status command, 0&#215;0000, and reading the result?</p>
<p>I have working code in SVN located here: <a href="http://svn.everythingrobotics.com/strobist/mk1/trunk/arch/pic16f88-boostc/src/" rel="nofollow">http://svn.everythingrobotics.com/strobist/mk1/trunk/arch/pic16f88-boostc/src/</a></p>
<p>The test_rfm code sends out a string of data on the TX and the Rx receives and lights up led if all good.  Code is fairly well documented and the RFM12 library works in polled mode, will also give you base configs to get started, although its the 915MHZ band it should work on 433MHZ</p>
<p>A couple of things to check:</p>
<p>1) Before you turn the receiver on are you resetting the FIFO?</p>
<p>2) If you are using SPI to read data from RFM then make sure you set the fifo to interrupt on 8 bits, that way when you read a status on the reciever the first bit is the receiver interrupt, if this is a 1 then a valid character has been received and then you can read it via the FIFO read command.</p>
<p>3) When transmitting make sure that when you send out your packet make sure preamble is min of 3 bytes then sync code then your data.  Also make sure that there is no interruption or pause in the process, if there is then receiver will loose sync after certian time and you need to repeat the sync process.</p>
<p>4) When transmitting are you checking the status of the TX register interrupt?  it is the first bit of the 0&#215;0000 status when in Tx mode.  Only when it is 1 can you write the next byte to the Tx register.  What I do is write the first two bytes into the Tx register, turn on the Tx then monitor the status bit, write the next byte and so on then when I&#8217;ve transmitted my complete packet I then write a couple of preamble bytes to the Tx register and turn off the TX. so that way the Tx register is flushed before I turn off the TX</p>
<p>5) make sure when turing on Tx or Rx that you allow for timing for tx/Rx to settle before transmitting.  These are in the spec sheet as I can&#8217;t remember off hand what they are.  i.e. if you are turning on the whole Tx/Rx chain then it takes longer to stabalize than say having the oscillators etc are already enabled and all you are doing is enabling the PLL etc then it&#8217;s a very short turn around time.</p>
<p>6) As its in unlicensed band there will be interference around, try changing frequencies.</p>
<p>7) Start with a datarate of 9600bps to get it all working then change speed to the required datarate once you are getting successful Tx and RX.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tenson</title>
		<link>http://blog.strobotics.com.au/2007/11/26/pic-spi-and-the-rfm12/comment-page-1/#comment-314</link>
		<dc:creator>tenson</dc:creator>
		<pubDate>Wed, 26 Mar 2008 19:13:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingrobotics.com/2007/11/26/pic-spi-and-the-rfm12/#comment-314</guid>
		<description>Hi,

I&#039;m working on project with RFM12B and have been wandering in the dark for 3 days now.
It seems I that transmitter is working as receiver changes it&#039;s status, but i can&#039;t get and data through.

The status of receiver in idle state randomly toggles between 0x0200, 0x0220 and 0x0260. If receiver is active this status changes to 0x03DF or 0x03EF (last byte is changing value).

The transmitter status randomly toggles between 0xA100 and 0x2100.

I would like to know you get similar status on Rx/Tx side?</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I&#8217;m working on project with RFM12B and have been wandering in the dark for 3 days now.<br />
It seems I that transmitter is working as receiver changes it&#8217;s status, but i can&#8217;t get and data through.</p>
<p>The status of receiver in idle state randomly toggles between 0&#215;0200, 0&#215;0220 and 0&#215;0260. If receiver is active this status changes to 0x03DF or 0x03EF (last byte is changing value).</p>
<p>The transmitter status randomly toggles between 0xA100 and 0&#215;2100.</p>
<p>I would like to know you get similar status on Rx/Tx side?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen Eaton</title>
		<link>http://blog.strobotics.com.au/2007/11/26/pic-spi-and-the-rfm12/comment-page-1/#comment-72</link>
		<dc:creator>Stephen Eaton</dc:creator>
		<pubDate>Tue, 27 Nov 2007 02:43:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingrobotics.com/2007/11/26/pic-spi-and-the-rfm12/#comment-72</guid>
		<description>As a side note I will be re-visiting the SPI library and it&#039;s timing down the track, as the problem with the bit bang functions is they are blocking, i.e. I can&#039;t do anything else until everything is send.  The SPI Library uses non blocking functions to do the sending and receiving.</description>
		<content:encoded><![CDATA[<p>As a side note I will be re-visiting the SPI library and it&#8217;s timing down the track, as the problem with the bit bang functions is they are blocking, i.e. I can&#8217;t do anything else until everything is send.  The SPI Library uses non blocking functions to do the sending and receiving.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.351 seconds -->

