I'm Not a Genius so it Takes Longer...

lardom · 2018-06-16 16:48

I've been trying to understand the "Square Wave" object well enough to explain it to myself in plain English because I'm working on a project that involves IR serial communication: I know you don't have to understand 'how' the code works in order to use it but I 'want' to understand it. It's part of my learning process.
For several days I had the Propeller manual PDF open. I had my calculator and scratch paper in front of me. "How does the counter transmit IR at a specific frequency for a specific length of time?"
Finally, after three days I saw the key: The transmit is controlled by toggling DIRA.
I have asked myself since I started programming "Can I do it?" So far, at least, "Yes, I can".

msrobots · 2018-06-16 20:17

Yes, this is where programming starts to be fun.

Reading other peoples sources and finally seeing them pieces falling together and seeing the whole program.

I spend days maybe even weeks looking at Lonesock's PASM sd-block driver from FSRW. What a cool piece of code. And if you look long enough at it you can see the difference between lonesock's handwriting and kuroneko's handwriting.

I can not praise JonnyMac more than I already do, his code is simple beautiful.

So 'Yes you can'

Enjoy

Mike

lardom · 2018-06-16 23:10

@msrobots, kuroneko was brilliant. I have some of his code in a folder on my desktop that he wrote for me when I was trying to understand "wear-leveling". I have another folder where I store many of the gems I get from JonnyMac. He has helped me 'big time'.
I love the Propeller and this forum. There's no other way to say it.

Genetix · 2018-06-17 06:39

lardom,

I think Chapter 7 of the PE Kit text will answer some of your questions.
It's on the Counter modules and starts on page 125.
https://www.parallax.com/downloads/propeller-education-kit-labs-fundamentals-text
https://www.parallax.com/downloads/propeller-education-kit-labs-fundamentals-example-code

And some of the Propeller Application Notes.
https://www.parallax.com/downloads/an001-propeller-p8x23a-counters

https://www.parallax.com/downloads/propeller-p8x32a-documentation

lardom · 2018-06-17 15:28

@Genetix, I'm going to experiment with PWM that runs at 38.004 Khz with a duty cycle between 15% - 20%. I will modulate it by toggling DIRA. If that works next next goal will be to send 8-bit data packets with a start bit. I won't get too far ahead of myself at this point.

Publison · 2018-06-17 15:39

Have you checked the OBEX for examples?
http://obex.parallax.com/search?search=ir

lardom · 2018-06-17 16:12

@Publison, Yeah, I have. Let me give you an example of some of what I'm studying:

PRI Fraction(a, b, shift) : f

  if shift > 0                                   'if shift, pre-shift a or b left
    a <<= shift                                  'to maintain significant bits while 
  if shift < 0                                   'insuring proper result
    b <<= -shift
 
  repeat 32                                      'perform long division of a/b
    f <<= 1
    if a => b
      a -= b
      f++           
    a <<= 1

"a" = frequency and "b" = clkfreq. Deciphering that will take some work. 80M / 38K = 2,105.263158.
Rather than write that out with scratch paper and a calculator I decided to try a basic test first. If my test fails I will hand write that repeat loop to see what happens.

Genetix · 2018-06-17 16:21

lardom,

Are you trying to do something specific or just playing around?

Also what is the baud rate and do you know if the receiver is strict or loose on timing?

lardom · 2018-06-17 16:54

Genetix wrote: »

lardom,

Are you trying to do something specific or just playing around?

Also what is the baud rate and do you know if the receiver is strict or loose on timing?

Ultimately, I want to build a 433Mhz transmitter that transmits bytes. I had success a couple of years ago with the nRF24L01 transceiver when I built a wireless mobile robotic arm with pan/tilt for a camera.
I think the SONY remote protocol is a great place to start. All I need is a start-bit, a digital 'one, a digital 'zero' and an 'interval'.
In my thinking the same 'ASK' principle that would work for a 433 Mhz transmitter should work for an IR version.
I 'could' just use what's already written but if there is no challenge I'll lose interest. And I'm kind of hoping that it'll be something I can share.

Genetix · 2018-06-17 17:24

lardom,

If I am hearing you right then it sounds like you need some kind of transmission protocol with error correction.

For IR you can greatly simplify your life and just use a 555 to generate your 38 kHz carrier.
Have the Propeller turn the 555 on and off as needed and when you are confident then you can have the Propeller also generate the carrier.

lardom · 2018-06-17 18:23

Genetix wrote: »

lardom,

If I am hearing you right then it sounds like you need some kind of transmission protocol with error correction.

For IR you can greatly simplify your life and just use a 555 to generate your 38 kHz carrier.
Have the Propeller turn the 555 on and off as needed and when you are confident then you can have the Propeller also generate the carrier.

I thought about using a 555 but I keep telling myself "A 433Mhz transmitter generates its own carrier frequency and it's not limited to line of sight operation."
Concerning error correction I will include a start bit for the carrier and send an additional byte which I call a 'sync byte' for the device I want to control. I have used 'sync bytes' in the past to clear a set of variable arrays and identify which mode I want to operate.
I don't know how much noise I'll run into but I'll deal with it if it becomes an issue.

Mike Green · 2018-06-17 18:41

It's always better to plan for difficulties ahead of time. A really simple protocol involves using a checksum or parity bits on each packet of information. You can send multiple copies of the command as well and require 1 or 2 copies to be received correctly ... something to reduce the sensitivity to noise or other interference.

lardom · 2018-06-18 01:41

Mike Green, Thanks. I do need to learn about checksums and parity bits.

JonnyMac · 2018-06-20 12:19

I have two recent commercial projects that use a checksum byte appended to the packet before transmission. Here's the code for calculating the packet checksum:

pub crc8x(p_src, n) : crc | b                                     
                                                                  
'' Returns CRC8 of n bytes at p_src                                
'' -- implementation by Micah Dowty                               
                                                       
  repeat n                                                        
    b := byte[p_src++]                                            
    repeat 8                                                      
      if (crc ^ b) & 1                                            
        crc := (crc >> 1) ^ $8C                                   
      else                                                        
        crc >>= 1
      b >>= 1

Let's say you have a packet that is eight bytes long. You need a buffer that is at least one byte longer (for the checksum). My projects have code that generally looks like this:

  build_buffer
  buffer[8] := crc8x(@buffer, 8)
  tx_buffer(@buffer, 9)

After you build your buffer, pass its address and the number of bytes in the packet. Add the checksum to the packet and send. The receiving end runs the same method on all but the checksum byte and does a comparison. Easy-peasy. I used this in my laser-tag project, and a recently completed arrow-board (those big, lighted signs with arrows that you see around road construction).
In case you were wondering, the CRC8 method is the same as used in 1-Wire communications.

lardom · 2018-06-21 14:23

@JonnyMac, Thanks. I'll add that code to my work folder. Just so you know I'm making slow but steady progress. You mentioned that the beauty of the Prop is that you can test both tx and rx together on one chip. That was a huge revelation. My original plan was to use two Propellers.
I also had to think of a way to test sending bytes serially which is my main goal. IR, 433Mhz or ultrasonic as a medium would be a secondary goal. I decided to connect the rx pin to a voltage divider which does the job I hoped it would.

JonnyMac · 2018-06-25 02:13

If your transmit and receive processes are running in separate cogs, you do not need external connections for testing; assign them to the same pin and Robert is your mother's brother. I do this all the time.

jmg · 2018-06-25 03:17

lardom wrote: »

I thought about using a 555 but I keep telling myself "A 433Mhz transmitter generates its own carrier frequency and it's not limited to line of sight operation."

If you want 433MHz, that's moving into proper RF chip territory, but there are chips available that do either transmitter or transceiver.
The appeal of supporting Transceiver, is a simpler BOM and you can add diagnostics.
SiLabs, Microchip and OnSemi (etc) have useful looking parts in that area.

You could also look at 2.4GHz, as I see more have IC's / modules there. Zilog offer Zigbee 2.4GHz chip, at what look like good prices, or there is WiFi from companies like Expressif

lardom · 2018-06-25 04:10

@JonnyMac, I'm excited. I did a test that incremented from 0 to 254 in a repeat loop. My tests appear to run faster than the nRF24L01. The additional speed is due to 'The JonnyMac Effect". I studied your "pos detector" code closely which made a huge difference in speed. Thank you!
I ordered some 433Mhz modules which I should get tomorrow.
In future tests I will assign transmit and receive to the same pin. When I was working on my nRF24L01 project I used two Props. It is 'so' much easier to program using F10.

lardom · 2018-06-25 12:25

jmg wrote: »

If you want 433MHz, that's moving into proper RF chip territory, but there are chips available that do either transmitter or transceiver.
The appeal of supporting Transceiver, is a simpler BOM and you can add diagnostics.
SiLabs, Microchip and OnSemi (etc) have useful looking parts in that area.

You could also look at 2.4GHz, as I see more have IC's / modules there. Zilog offer Zigbee 2.4GHz chip, at what look like good prices, or there is WiFi from companies like Expressif

The nRF24L01 operates at 2.4Ghz. With that transceiver I built a wireless, mobile robotic arm with pan/tilt for a camera. What appeals to me about the 433Mhz modules is that they have no on board processor. In this case the Propeller generates an 8-bit data packet at a faster rate than the nRF24L01.
Something else I learned in my tests is that the Prop can both generate a pulse 'and' measure a pulse down to the clock cycle. That means you should be able to create a transmitter-receiver pair simply by having a unique start-bit pulse size.
Of course for telemetry you need a second pair of modules. That, to me, is the downside.

lardom · 2018-06-26 19:37

RANT ALERT!
I'm done with 433Mhz modules unless I want to flash LEDS. I could only get the transmitter/receiver pair to change state three times a second! They failed to change state as soon as I tried to speed it up by writing this:

waitcnt(clkfreq / 4 + cnt)

I wanted to try to create an OOK transmitter demo for the OBEX that could transmit both RF and IR. I'm not giving up but I'm going back to high speed transceivers. Thanks to Bean, JonnyMac and Mike Green I learned some major lessons that I will put to good use.
I may return to the nRF24L01 which is a SPI device and transmits using FSK and is reliable. The problem is that the nRF24L01 will reset if the power supply goes below 3.3V and it doesn't take much to fry the PCB. Still, I was able to control a device from 230' without errors or an external antenna.

I'm Not a Genius so it Takes Longer...

Comments