Shop OBEX P1 Docs P2 Docs Learn Events
Pulse Width Modulation Question — Parallax Forums

Pulse Width Modulation Question

DavidicusDavidicus Posts: 20
edited 2012-07-20 05:03 in Learn with BlocklyProp
Protocol.jpg

I am working on a (non-school) project and think I'm on the right track, but I wanted to check with all of you. Above is a diagram of a serial bit stream that I am trying to decipher. I have been told that the bit stream is sent roughly 20 times/second. I am assuming that the sentence "Message latched 17.6 ms after last clock transition" means that there is a 17.6 ms "dead spot" in-between 32 bit messages where the input would be low. I am assuming that this is how I can determine the starting point of the message. Then, 32 bits are sent. Now, here is what I am thinking on the timing of the bits:

With 20 messages sent per second, that means that the time allowed for each message is 50 ms. With 17.6 ms of dead time, that leaves 32.4 ms. With 32 bits in each message, the rising edge of each bit will be roughly 1 ms apart (Is this right???). If it is a zero, it will immediately (before the 12.6 microsecond latch window) fall back to zero. If it is a one, it will stay high for at least 12.6 microseconds. Then, some time within that particular millisecond, it will fall back to low in preparation for the next rising edge.

If my assumptions are correct, this means that I can perform the following steps to determine the message:

1. Determine at what point I am in the dead time window by timing the amount of time the input is low. If it exceeds 2 ms, I am in the window.
2. Once determined, wait for the rising edge.
3. Once received, wait 12.6 microseconds.
4. Determine the status of the input (high or low).
5. Use the remaining time in that particular millisecond to store that bit in a variable.
6. Repeat 2-5 for the remaining bits.
7. Once all 32 bits are received, complete other tasks related to the data received within the 17.6 ms window before the next message begins.

Please correct me if I am wrong. I wish to be told if I am way off-base or even if I'm only slightly off-base. :-)

Lastly, I think the only controller capable of doing the above is the Propeller. Is this true? I have been using the BS2 for a number of years and am ready to make the change if I need to. It should be a fun ride!!

Thanks in advance.
1024 x 805 - 54K

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-07-18 07:18
    You don't really have enough information (yet) to determine the timing of this protocol. It looks like an IR remote control sort of message with a short pulse indicating a zero and a long pulse indicating a one with the threshold for this set at 12.5us. This would be way too fast for a Stamp to handle without using external hardware. A Propeller would be best.

    "... latched 17.5ms ..." means that there are no pauses greater than 17.5ms within a message. Between messages, the pause could be any length. If messages are send about 20 times a second, that's roughly 50ms per message. The message itself could be sent in less than 1ms (20us x 32 bits).
  • DavidicusDavidicus Posts: 20
    edited 2012-07-18 10:01
    I appreciate the quick reply and the information!

    I was finally able to get a hold of the manufacturer, and he told me that, indeed, the message is complete within 1 ms. The total time for each bit is roughly 20 µs. That means, as far as I understand, I have roughly 7 µs to store the bit and get ready for the next incoming pulse.

    Is the Propeller capable of this resolution in one cog, or do I have to spread this out over multiple cogs? If my understanding is correct, I should be able to receive the messages using one cog, and then, use another cog to do other tasks once each message is received. Is this correct?
  • pik33pik33 Posts: 2,364
    edited 2012-07-20 05:03
    Yes, it is capable to do it in one cog. 7 µs=140 standard instructions. This should be sufficient. There are also 2 counters in a cog that you can use.
Sign In or Register to comment.