- Posts: 4402
Protocol Stacks
06 Aug 2012 17:25 #924
by PhracturedBlue
Replied by PhracturedBlue on topic Protocol Stacks
yes, but why include rand() for just one call? if I'm going to provide a seed, why not just use it directly as the Random number. Randomness is only necessary between transmitters, not between startups.wuselfuzz wrote:
PhracturedBlue wrote: I'm not sure about an RNG (seems wasteful to include a prng just for this one function), but I thought the crc of the model file would make a good id when none is specified.
newlib should supply rand(). Needs a seed, though, or it's not random at all (see xkcd).
A good seed would be RSSI values from the CYRF.
Please Log in or Create an account to join the conversation.
06 Aug 2012 17:46 #932
by FDR
I did the same yesterday...
Replied by FDR on topic Protocol Stacks
wuselfuzz wrote: Dang, I left my 2402 on. ><
I did the same yesterday...
Please Log in or Create an account to join the conversation.
06 Aug 2012 18:03 #935
by PhracturedBlue
But basicaly, just run the relevant init code, put the module in receive mode, and run a loop waiting for 16 byte packets.
you should be able to hack up the existing protocol code in short order to do that.
Replied by PhracturedBlue on topic Protocol Stacks
sure, but I don't think the UART can keep up. Using my salea is easierwuselfuzz wrote: Hmm.
Couldn't we use a devo8 as an rx to dump the transmitted packets of other transmitters?
But basicaly, just run the relevant init code, put the module in receive mode, and run a loop waiting for 16 byte packets.
you should be able to hack up the existing protocol code in short order to do that.
Please Log in or Create an account to join the conversation.
06 Aug 2012 18:17 - 06 Aug 2012 18:18 #937
by PhracturedBlue
Replied by PhracturedBlue on topic Protocol Stacks
Actually, that isn't the answer I wanted to see. Now we need to do even more testingFDR wrote:
Yep, you were right...PhracturedBlue wrote: ahh..that is very good to know. it explains why my 'random' id didn't work
Can you try these values?
1048575: OK
524288: doesn't bind
524287: OK
262144: doesn't bind
262143: OK
131072: doesn't bind
131071: OK
That will tell me if it is dependent on the MSB being set in the MSB byte
Please Log in or Create an account to join the conversation.
07 Aug 2012 22:15 - 07 Aug 2012 22:23 #961
by wuselfuzz
Replied by wuselfuzz on topic Protocol Stacks
Microseconds, pwm duty cycle.
1500us is center position.
/edit: It might be a good idea to plug some of your logic probe inputs to the servo outputs of the rx to get an actual number instead of "well, the servo moved to about 90% deflection from center".
1 degree servo deflection is about 100us PWM difference.
I once implemented a 24 channel servo controller on this guy:
1500us is center position.
/edit: It might be a good idea to plug some of your logic probe inputs to the servo outputs of the rx to get an actual number instead of "well, the servo moved to about 90% deflection from center".
1 degree servo deflection is about 100us PWM difference.
I once implemented a 24 channel servo controller on this guy:
Please Log in or Create an account to join the conversation.
09 Aug 2012 07:45 - 09 Aug 2012 20:52 #999
by wuselfuzz
Replied by wuselfuzz on topic Protocol Stacks
Here's a bunch of bind packets from a tx2402 to an rx2435:
Looking further into it. Just created my dump parser and all.
Each line is an individual packet, retrieved by SPI Command 132. Didn't strip the 0xFF on MISO that's received when transmitting the command byte.
/edit: removed the zeroes, empty MISO string from the dump was interpreted as a zero by perl.
Those four packets were repeated over and over.
In comparision to wk2x01.txt, Bytes 10 and 11 seem to be constant during a single bind and change after rebinding. The txt says, byte 12 has a counter in the lower nibble and TxID3 in the upper nibble.
I only observed 0x4 in the lower nibble and the sequence 0x0, 0x8, 0x4, 0xc, 0x2, 0xa, 0x6, 0xe, 0x1, 0x9, 0x5, 0xd in the upper nibble.
/edit again:
Data packet, throttle at zero. I'm not sure if this corresponds to "Bind 1", did some quick dumping right before work today.
Same bind, throttle at max:
/edit: I checked my raw logs again. All four packets, a channel switch is issued to the CYRF. Byte 13 in the received packet always corresponds to the channel the packet is received on.
... removed to avoid confusion: MSB first/LSB first mixup...Looking further into it. Just created my dump parser and all.
Each line is an individual packet, retrieved by SPI Command 132. Didn't strip the 0xFF on MISO that's received when transmitting the command byte.
/edit: removed the zeroes, empty MISO string from the dump was interpreted as a zero by perl.
Those four packets were repeated over and over.
In comparision to wk2x01.txt, Bytes 10 and 11 seem to be constant during a single bind and change after rebinding. The txt says, byte 12 has a counter in the lower nibble and TxID3 in the upper nibble.
I only observed 0x4 in the lower nibble and the sequence 0x0, 0x8, 0x4, 0xc, 0x2, 0xa, 0x6, 0xe, 0x1, 0x9, 0x5, 0xd in the upper nibble.
/edit again:
Data packet, throttle at zero. I'm not sure if this corresponds to "Bind 1", did some quick dumping right before work today.
...Same bind, throttle at max:
.../edit: I checked my raw logs again. All four packets, a channel switch is issued to the CYRF. Byte 13 in the received packet always corresponds to the channel the packet is received on.
Please Log in or Create an account to join the conversation.
Time to create page: 0.086 seconds
-
Home
-
Forum
-
Development
-
Development
- Protocol Stacks