Ko Propo Mini-z Protocols ASF/MHS

[stbn72]

Hi, i would like this protocols to be added

[FilePhil]

Hey,
Support for the ASF protocol would be awesome.

I have found this guide [#379](#379 (comment))
and tried to capture the needed sequences.

I used a BitScopeBS05U so i could only record on 8MHz.
ASF_8mhz_dumps.zip

Please let me know i this is enough resolution or if I should order another logic analyzer.

ASF Module Overview:

Thank You,
Best regards Phil

[pascallanger]

Wow it looks quite small to solder wires on this board... I can see only 3 arrows on the PIC does it mean you haven't connected one of the signal (blue)?
Sorry but can you extract the SPI data from your dumps? or point me to the needed software (I've tried BitScopeLogic with no luck)? Right now I can't read the files in the zip file to see if they are good or not.
The easiest would be to get a cheap saleae 8ch logic analyzer for around $10 on ebay.

[FilePhil]

Hey, yes I found only these Three Pins on the mcu, but i will recheck it tomorow, mabye I missed the Connection.
The Data in the ZIP should be PulseView Session files like in the other Issue. I converted of the Data Form the Bitscope, because the DDR/CSV is not very usefull...

[FilePhil]

Today I got the Logic Analyser and went to work:
I checked the MISO and MOSI Pins again and It seems to be that they are connected to the same pin on the MCU.
The soldered wires is not bridged with any other Pin on the MCU.
Maybe they use the 3 Pin SPI Mode stated in the Datasheet?

This interface may be optionally operated in a 3-pin mode with
the MISO and MOSI functions combined in a single bidirectional
data pin (SDAT). When using 3-pin mode, user firmware must
ensure that the MOSI pin on the MCU is in a high impedance
state except when MOSI is actively transmitting data.
Datasheet CYRF6936 Page 5

I probed the SPI with PulseView in 12MHz Mode, here are the Session Files:
ASF_12MHz_PulseView_SRs.zip

Hopefully this helps with the analysis, Thank you!

[pascallanger]

I've only looked at the On_Idle file for now.
Wow they are a bit crazy on the cyrf polling...
They are nearly using all the default values of the cyrf for the init.
They transmit only on one channel but they keep listening on that channel so I think they have a system to switch from one channel to another as needed. (Traxxas TQ is the other protocol doing something like this).
CRC16 is disabled so there must be a CRC in the payload itself.
The payload is 9 bytes. There must be an ID 2 to 5 bytes, 2-4 channels 1 to 2 bytes per channel and a CRC 1-2 bytes.
More to follow...

[pascallanger]

I see that some TXs/RXs have 4 channels. Do you confirm?
Your TX has only 2 channels right?
How many channels do you have on your RX?
What's the bind procedure? I have some trouble to see how the bind works... I have the impression that the RX will bind to any TX around...

[pascallanger]

Bind payload 4 bytes (from "Binding_Fresh" and "Bind_Long")

AA	01	AB	31
Bind	ID0	ID1	ID2

Timing
Packets are sent every 2434µs.

RF channels
Set 00 Receive
Set 52 Read RSSI -> Nothing
Set 54 Receive
Set 52 Read RSSI -> Nothing
Set 04 Read RSSI -> Nothing
Send bind payload

Why is it listening on 52 and 54?
What happened for these 2 runs which was different from Binding below? IRQ?

From "Binding"
Scan every even channels from 04 to 50
Set 00 Receive
Set 52 Read RSSI -> Nothing
Set 54 Receive
Set 52 Read RSSI -> Nothing
Set 04 Read RSSI -> Nothing
Set 06 Read RSSI -> Nothing
....
Set 50 Read RSSI -> Nothing
Redo RSSI scan but stops at 20
Send normal payload with normal timing

Normal payload 9 bytes

01	AB	31	BF	77	7D	FF	AA	5C
ID0	ID1	ID2	CH LSB?	STR	THR	CH3	CH4	checksum

Payload
CH_LSB -> this byte looks like the concatenation of the 2 low bits of the 4 channels but it is hard to see on the dumps: CH4.b1 CH4.b0 CH3.b1 CH3.b0 THR.b1 THR.b0 STR.b1 STR.b0
STR 30..7C..CC -> 8 upper bits, 10 in total. Can be extended to 00..7F..FF ?
THR 12..7C..DE -> 8 upper bits, 10 in total. Can be extended to 00..7F..FF ?
CH3 01..FF -> 8 upper bits, 10 in total. Can be extended to 00..7F..FF ?
CH4 most likely
Checksum=sum(P[3..7]) , the ID is excluded from the calculation which is ok
RF channels
Try to receive for a long long time on channel 04. Then channel 04 is used to send and listen.
What happens if something is received on channel 0x04 during the receive or transmit phase?
Timing
Packets alternates between 6957µs and 9047µs (spending just more time to listen). So the overall period is 16ms.

[pascallanger]

I think its 2 channels (i would only need 2 i guess)

I've found many RXs with 4 channels: https://fr.aliexpress.com/item/1005003078678987.html

[FilePhil]

Hey,
I see that some TXs/RXs have 4 channels. Do you confirm?
Yes I habe Seen the New RX with 4 Channels.

Your TX has only 2 channels right?
It can output 3 Channels, should I try to make a recording?

How many channels do you have on your RX?
The Mini Z MR-02/03 have 3 Channels RX, the Thrid is only for turning on Lights.

What's the bind procedure?

1. Hold Button on the TX Module
2. Turn on TX
3. Release Module Button
4. Hold BIND Button on the RX/Mini-z
5. Turn On RX/Miniz
6. Release BIND Button
7. Wait for the Red light to go to Solid
8. Power Cycle both

[pascallanger]

Can you record CH3?

[FilePhil]

Okay, I will Try it Later.
The Module uses PPM from the TX, mabye I can Simulate the 4. Channel, if it would help?

[pascallanger]

Having the 3rd channel should be enough to clear the assumptions.
My guess is that we will see AUX1 going from FF to 00 and CHLSB going from Bx to 8x.

[pascallanger]

I need to check my decoder there might be something I'm not seeing on the bind... I do see the difference with On_idle but I can't see what's helping for the bind.

[FilePhil]

Okay mabye i have to unbind the RX first to see the Binding.

[pascallanger]

Okay mabye i have to unbind the RX first to see the Binding.

Not sure how you can unbind it unless you have a second TX?

[pascallanger]

Okay mabye i have to unbind the RX first to see the Binding.

Was the RX powered on and in bind mode when you launched the "Binding" capture?
I see the TX sending a packet and kind of listening for something (an answer?) which never comes... It even never switches to normal mode during the dump.

The only thing I see different during the bind is that the TX looks for a free channel before transmitting.
In normal mode it uses a channel (last used? have you done all your dumps On/STR/THR without powercycling the radio?) and listen on this channel. I assume that if it finds another TX on that channel it will switch to a new one but that needs to be looked at because there might be a notification to the RX that the RF is about to change.
Loads of questions and unknowns...

Traxxas TQ is also transmitting on a single channel, use the last known good channel (same as above?), and if it hears about another TX, it will tell the RX to meet at another channel before switching. If the RX is lost, it doesn't scroll through all the RF channels (may be that's what the ASF RX does but that can take a long time to scan the full 39 available channels so a lot of packet loss) but instead it sends "help" on a specific channel, the TX receives it and sends a "hello" packet saying I'm using this specific channel come to me.

[pascallanger]

Is it possible to bind multiple RXs to your TX?
What happens in this example: Bind your RX but power it off, launch a new bind on the TX with the RX still off, power of the TX. Will the RX reconnect after that? You might need to retry a few times to make sure the TX has selected another channel, ie if it works when you power on the RX, power it off, put the TX in bind, power cycle and power the RX.

[FilePhil]

Was the RX powered on and in bind mode when you launched the "Binding" capture?
No, You have to first put the TX into Binding Mode than the RX. The other way around does not work.

It even never switches to normal mode during the dump
You have to Powercycle after the Binding, before that nothing moves.

Have you done all your dumps On/STR/THR without powercycling the radio?
I captured each dump on a fresh Powercycle.

Is it possible to bind multiple RXs to your TX?
Yes, they also work on the same time. A Race against yourself is possible :)

What happens in this example: Bind your RX but power it off, launch a new bind on the TX with the RX still off, power of the TX. Will the RX reconnect after that?
The RX reconnects every time, I tried the sequence like 5 times.

I have also recorded a new Binding with an previous unbound RX (I borrowed another TX)
ASF_12MHz_PulseView_Binding.zip

[FilePhil]

I tried also to Capture CH3, but on the TX I can only map it to toggle buttons, so full left or full right.
ASF_12MHZ_PulseView_CH3.zip

[pascallanger]

CH3 is showing what I was expecting. It goes from 01 to FF. For the 2 additional bits I have been able to correlate the change and one of the 2 bits so I'm sure of the position of CH4 and CH3 but not STR and THR. The last 2 bits are hard to identify due to the noise, they keep moving quite a lot...

[pascallanger]

Binding_Fresh and Bind_Long are completly different compare to Binding. There is actually a 4 bytes bind packet being sent with the ID.
Binding follows the same path but somehow does not get what it wants, continue to scan and finally switches to normal mode.
From the SPI dumps I can't see what's different but I guess the IRQ pin (how easy will it be to add a probe on this pin?) is signaling that a packet has been received (from the RX in bind mode) which triggers the bind packets to be sent.

I'm wondering if I can simply scan for a free channel 04..50 and blindly send bind packets. Same for normal mode by the way.

FYI I keep updating my first post with my findings and questions

[pascallanger]

I can now code this protocol but I will need other dumps to see what happens when the frequency is used. Your TX is sending always on 4 so you could start recording, turn on the multi module which will also sends on 4 and we will then see what happens.

My guess is that on detection of a used channel the alternating normal packets will be sent on 2 different channels current and a free channel for a (long) period of time and then fully switch to this new channel for a "smooth" transition.

[pascallanger]

Please test v1.3.4.3 SFC available here: https://downloads.multi-module.org/latest-test/
The documentation is located here: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#kyosho3---98
It uses @FilePhil ID and RF frequency for now for test purposes.

For @FilePhil, please test as follow:

1. take a RX bound to the TX you use for dumps and power it on

• create a model using the new protocol Kyosho3/ASF
• you should have control right away -> be careful with throttle...

2. take an unbound RX

• put the RX in bind mode
• launch a bind on the TX
• bind should work and you might even get control right away

For others who also wants to test, just follow step 2 and report.

[FilePhil]

Awesome, how fast you managed it.
I tested the Firmware:

• The Throttle and Steering works, but with heavy stuttering and the Throttle seems not to reach full Throttle. See Video
• One time the Controls doesn't work for a few seconds and then the steering moves without input for a few times.
• Binding a new RX does not work. After starting the Bind on the TX, it beeps after 2s and the binding exits without any actual binding.

[FilePhil]

Also i Attached the IRQ Pin to the Logic Analyser and recorded the Sessions:
ASF_12MHz_IRQ_PulseView_SRs.zip

[pascallanger]

Awesome, how fast you managed it. I tested the Firmware:

• The Throttle and Steering works, but with heavy stuttering and the Throttle seems not to reach full Throttle. See Video
• One time the Controls doesn't work for a few seconds and then the steering moves without input for a few times.
• Binding a new RX does not work. After starting the Bind on the TX, it beeps after 2s and the binding exits without any actual binding.

Can you test with v1.3.4.4 ?

For Throttle not reaching maximum speed, it might just be due to the stuttering which I hop is solved in this version.
What I've done so far is to assign directly what the radio sends to the channels. The output range from multi is 19..E6, Throttle on your original TX is 12..DE, so as you can see your original TX goes a little lower 12/19 but at the top multi goes beyond DE/E6.
You can increase the range if you want, far more than the original TX, if you enable "Extended limits" and set your outputs (not mixers) to 125% giving 00..FF. I can change that to whatever would work but that's how it is so far.

[FilePhil]

Thanks, I tested v1.3.4.4:
Throttle and Steering works without any visible Issues while bench testing.

Binding a new RX works if the binding on TX is launched first and then the binding on the RX is started (Releasing the Binding Button on RX).
But you have to be quick, because the TX binding terminates after 2s.
Is it possible to expand to 10s or 20s ?

The binding seems to reuse my original TX ID for the new bound RX.
I can control also the RX bound to the MultiModule TX with the original TX .
So I can not use both at the same time for different RX.

[pascallanger]

We are not done yet.... We will change the ID later.
I would like you to do the following, you might only have one try so prep yourself:

• use an already bound RX but do not power it on
• start a recording and power on the original TX, save the file but don't turn off the TX
• with the original TX still powered, start a recording and then quickly power on multi (be careful here powering up the radio and module takes time so the recording must be long enough) and save the file
• power off the original TX and multi, power on the RX, start a recording and power on the original TX. Save the file. Is the RX still working (assume yes but...)?

[FilePhil]

I followed the Steps and the RX is still working on the original TX and Multi.
ASF_Scenario_1.zip

[pascallanger]

Ok so strangely when there is a clash the TX doesn't change the RF frequency but instead shorten the packet (5 bytes instead of 9) and sends it less often which means that only steering is getting out every 16ms... Is it because it has seen the same ID?

[pascallanger]

Can you try v1.3.4.5 which supports multi IDs?
Try to bind any RX, is it working? Verify connectivity after a power cycle of the RX, connectivity after a power cycle of multi. Make sure that the RX doesn't work anymore with the previous TX.

Assuming it works, I would need 2 dumps of the original TX:

1. Turn on multi, start recording, power on the original TX and leave it idle
2. power on the original TX, start recording, turn on multi
   Make sure to record long enough in both cases

[FilePhil]

Try to bind any RX, is it working? Verify connectivity after a power cycle of the RX, connectivity after a power cycle of multi. Make sure that the RX doesn't work anymore with the previous TX.
Yes, it works to bind and the RX doesn't work anymore with the previous TX.
When the original TX is also on and i try the multi TX, the Multi RX start to stutter and after a few seconds the connections seems to be lost and i can not control it any more.

Assuming it works, I would need 2 dumps of the original TX
I recorded the Scenario one time without RXs powered on and one time with RXs on.
I don't know if its makes a difference.
ASF_Scenario_2_RX_off.zip
ASF_Scenario_2_RX_on.zip

I also noticed that the range is only around 1m, is this a test firmware thing? :)

[pascallanger]

I also noticed that the range is only around 1m, is this a test firmware thing? :)

This is unexpected and I don't see why since I'm setting the cyrf to full power unless you have checked low power...

[pascallanger]

Assuming it works, I would need 2 dumps of the original TX I recorded the Scenario one time without RXs powered on and one time with RXs on. I don't know if its makes a difference. ASF_Scenario_2_RX_off.zip ASF_Scenario_2_RX_on.zip

Too bad your TX has changed its RF channel outside of the dumps surely during your tests above. So I still don't have the info on what to do when there is a RF conflict...
I've updated the RF channel to match your current TX channel. You have only one chance to do the capture since it will change again when both TXs are up at the same time...

[FilePhil]

Okay new try, now the first time both turned on the same time:

ASF_Scenario_2_RX_On_first.zip

[FilePhil]

I recorded also a range test, where i am walked away with the RX.
Maybe something happens, when the Distance Changes.
ASF_Range_bigger_3m.zip

[pascallanger]

Okay new try, now the first time both turned on the same time:

ASF_Scenario_2_RX_On_first.zip

I've never asked for both TX to be turned on at the same time... I've asked first original, record then multi...
The dump is useless since it still doesn't show anything apart that at startup original TX saw another TX around and decided to select another free channel before transmitting 4s later. So back to square one I still don't know how they deal with an issue when another TX comes online with the same RF channel...

[pascallanger]

I recorded also a range test, where i am walked away with the RX. Maybe something happens, when the Distance Changes. ASF_Range_bigger_3m.zip

Nothing is going to change even at a distance since the RX doesn't send anything.
For the range issue, have you tried to power cycle everything after the bind?
On their side they transmit all the time at full power. On my side I transmit at low power during bind (to not bind all the cars around) and then when switching to normal mode I go to full power. So the car might get confused by this power switch. That's the only thing I can see. If that's the case binding the car then power cycling it should solve the issue.

The latest version I've pushed looks for a free channel before transmitting. Try that one out.

[FilePhil]

Okay new try, now the first time both turned on the same time:
ASF_Scenario_2_RX_On_first.zip

I've never asked for both TX to be turned on at the same time... I've asked first original, record then multi... The dump is useless since it still doesn't show anything apart that at startup original TX saw another TX around and decided to select another free channel before transmitting 4s later. So back to square one I still don't know how they deal with an issue when another TX comes online with the same RF channel...

Okay, I assume from the Answer you need only the 2. sequence, right?
I thought you need Both and did both sequences.
I have not powered them up at the same time.
I have tried to say, that I tested them not before the record.😅

To be clear this time:
Prepare:

1. Bind Original TX with RX, turn off
2. Update multi TX,
3. Powercylcle multi TX
4. Bind Multi TX with other RX, turn off

Record Sequence:

1. Power on the original TX
2. start recording
3. turn on multi
4. record for 30s

[FilePhil]

I recorded also a range test, where i am walked away with the RX. Maybe something happens, when the Distance Changes. ASF_Range_bigger_3m.zip

Nothing is going to change even at a distance since the RX doesn't send anything. For the range issue, have you tried to power cycle everything after the bind? On their side they transmit all the time at full power. On my side I transmit at low power during bind (to not bind all the cars around) and then when switching to normal mode I go to full power. So the car might get confused by this power switch. That's the only thing I can see. If that's the case binding the car then power cycling it should solve the issue.

The latest version I've pushed looks for a free channel before transmitting. Try that one out.

I did try to power cycle, but the same result.
I will test it again with the new Version.

[FilePhil]

I tested the Latest Firmware and the Range issue is resolved.

@pascallanger is the Sequence Planning OK?

[pascallanger]

I'm closing this issue as the code works as it is.

[stbn72]

I'm closing this issue as the code works as it is.

Hi, what about the MHS protocol?