SPI capture guide

I ues deviation firmware for a long time and now I want to contribute something for deviation,
I have ordered a logic analyzer ,and want to learn SPI capture.
Where can I get some guide or manual to teach me how to do it? I don't have any experience
about this, please help.

dc59 wrote: I ues deviation firmware for a long time and now I want to contribute something for deviation,
I have ordered a logic analyzer ,and want to learn SPI capture.
Where can I get some guide or manual to teach me how to do it? I don't have any experience
about this, please help.

I did this video sometimes ago

Thanks Seby,
What's setting of this option?




I will try to do it once I get my analyzer.

Those describe the number of samples that will be collected during the next capture.
The "24Mhz" option describes the rate at which samples will be captured.
Combined, they dictate a *capture period* that you should do all your communication sampling in.

- The more samples you take the longer the capture period
- The lower the sample rate the longer the capture period

You select these in combination to give you just enough resolution you need, but with enough samples that the capture period is long enough to do all your tests. Usually 8Mhz is fast enough so 50 Million samples lets you capture about 10 seconds of activity. You can increase the sample count to extend the capture period... but the file sizes grow quickly. That's why I generally break down captures into individual small single actions.

Edit: I forgot that there is a "trigger" mechanism that can be used to make the timing a little easier. I did not learn how to use that though.

greenfly wrote: Those describe the number of samples that will be collected during the next capture.
The "24Mhz" option describes the rate at which samples will be captured.
Combined, they dictate a *capture period* that you should do all your communication sampling in.

- The more samples you take the longer the capture period
- The lower the sample rate the longer the capture period

You select these in combination to give you just enough resolution you need, but with enough samples that the capture period is long enough to do all your tests. Usually 8Mhz is fast enough so 50 Million samples lets you capture about 10 seconds of activity. You can increase the sample count to extend the capture period... but the file sizes grow quickly. That's why I generally break down captures into individual small single actions.

Edit: I forgot that there is a "trigger" mechanism that can be used to make the timing a little easier. I did not learn how to use that though.

Thanks for your reply.
In Seby's video ,he just changed to '50 M Samples' , I didn't find he changed rate to 8Mhz , is 24Mhz ok for SPI capture ?
or I need to change it to 8Mhz?

dc59 wrote:

greenfly wrote: Those describe the number of samples that will be collected during the next capture.
The "24Mhz" option describes the rate at which samples will be captured.
Combined, they dictate a *capture period* that you should do all your communication sampling in.

- The more samples you take the longer the capture period
- The lower the sample rate the longer the capture period

You select these in combination to give you just enough resolution you need, but with enough samples that the capture period is long enough to do all your tests. Usually 8Mhz is fast enough so 50 Million samples lets you capture about 10 seconds of activity. You can increase the sample count to extend the capture period... but the file sizes grow quickly. That's why I generally break down captures into individual small single actions.

Edit: I forgot that there is a "trigger" mechanism that can be used to make the timing a little easier. I did not learn how to use that though.

Thanks for your reply.
In Seby's video ,he just changed to '50 M Samples' , I didn't find he changed rate to 8Mhz , is 24Mhz ok for SPI capture ?
or I need to change it to 8Mhz?

24mhz is ok, but will generate a huge capture file.
For TX captures, usually 8mhz is ok.
For RX captures, usually is needed more resolution. 16Mhz should be ok.

Those rates should typically be okay, but the minimum rate is determined by the frequency of the SPI clock signal. To not miss any transitions in the signal being sampled the sample rate needs to be greater than the fastest transitions in the signal (for example, a square wave has transitions twice every cycle so the sample rate needs to be at least twice the square wave frequency). Haven't tested but I'd expect the SPI decoder in the logic analyzer needs to see every SPI clock transition, so the sample rate needs to be more than twice the SPI clock frequency.

Sampling at the fastest rate possible to check the SPI clock frequency is a good place to start. Then depending on the clock frequency the sampling rate can be lowered to reduce the file size.

For some reason the SPI buses of two toy quads I've looked at have much higher SPI clock frequencies on the receiver than the transmitter.

Hi Durete & hexfet,

Thank you for both your advise me.
I try to capture my first shot, can anyone help me to check it right or wrong?
I just capture power on then finish binding , turn off.



If it's OK, I will upload the file.

Thanks again.

hexfet wrote: Those rates should typically be okay, but the minimum rate is determined by the frequency of the SPI clock signal. To not miss any transitions in the signal being sampled the sample rate needs to be greater than the fastest transitions in the signal (for example, a square wave has transitions twice every cycle so the sample rate needs to be at least twice the square wave frequency). Haven't tested but I'd expect the SPI decoder in the logic analyzer needs to see every SPI clock transition, so the sample rate needs to be more than twice the SPI clock frequency.

Sampling at the fastest rate possible to check the SPI clock frequency is a good place to start. Then depending on the clock frequency the sampling rate can be lowered to reduce the file size.

For some reason the SPI buses of two toy quads I've looked at have much higher SPI clock frequencies on the receiver than the transmitter.

Perfect explanation that I couldn't with my bad English
Hats off, Sir

@dc59

Yes, it looks good! I can see the clock and the chip select signals so I think your capture is working. A couple of things...

Set the SPI Analyzer to dump Hexadecimal...



Then just export the CSV file...

greenfly wrote: @dc59

Yes, it looks good! I can see the clock and the chip select signals so I think your capture is working. A couple of things...

Set the SPI Analyzer to dump Hexadecimal...

Then just export the CSV file...

OK~ Thank you very much.

I captured Eachine H8 mini SPI data as below:

~ 10MB Session data.
www.mediafire.com/download/2p3n5zzrbdm55...ni-SPI-LogicData.zip

~2.2MB Export CSV data
www.mediafire.com/download/vxue8tpbtyvuwm3/H8mini-SPI-CSV.zip

Can anyone help me to check it out and try to develop protocol?

Thanks.

dc59 wrote: I captured Eachine H8 mini SPI data as below:

~ 10MB Session data.
www.mediafire.com/download/2p3n5zzrbdm55...ni-SPI-LogicData.zip

~2.2MB Export CSV data
www.mediafire.com/download/vxue8tpbtyvuwm3/H8mini-SPI-CSV.zip

Can anyone help me to check it out and try to develop protocol?

Thanks.

You should save session & data also via the top right option menu

SeByDocKy wrote:

dc59 wrote: I captured Eachine H8 mini SPI data as below:

~ 10MB Session data.
www.mediafire.com/download/2p3n5zzrbdm55...ni-SPI-LogicData.zip

~2.2MB Export CSV data
www.mediafire.com/download/vxue8tpbtyvuwm3/H8mini-SPI-CSV.zip

Can anyone help me to check it out and try to develop protocol?

Thanks.

You should save session & data also via the top right option menu

Yes, I follow your tutorial to save session&data at #1 10MB file.

I've been using a cheap electronic timer to gauge the number of samples I'll need. I time a quick practice run-through of what I want to capture, then pick the next (longer) time available for the real thing.

The 16MHz sample rate worked for me, and didn't seem to generate un-useably large files.

I set very longcapture times, then manually stop the process when the right events are captured... there's no need to guess how much you need, when you stop capture the Logic software saves the file until that point

Trying to guess how many samples you need is super frustrating

robca wrote: I set very longcapture times, then manually stop the process when the right events are captured... there's no need to guess how much you need, when you stop capture the Logic software saves the file until that point

Trying to guess how many samples you need is super frustrating

Yep, me too. 100% agree

I put together these notes and illustrations to keep track of my own SPI analyzer efforts so that I could produce the same output each time. I hope this is helpfule. If anyone finds issue please let me know so that I can update or correct it.

1. Set the SPI decoder to show HEX



2. Set the SPI analyzer settings to match the channels as you've connected them. I think your channels should be:
MOSI: 1 (maybe -- and you can always swap this later)
MISO: 0 (and you can always swap this)
Clock: 2
Enable: 3 (enable is usually configured to be active when the value is low, but you may have to play with this)



3. Use the Options to set the analyzer to show HEX data. You will also use this menu to Save the capture (useful if other people need to be able to manipulate the settings against your capture) or EXPORT data (to save off the data only). I think some of the technical guys prefer the "Save Capture" approach.



4. Set up a trigger on the ENABLE or CLOCK line. Triggers tell the analyzer to begin collecting samples at a certain point. I usually set only one channel for a trigger. In my example I used a downward change on the enable line to tell the analyzer when to begin collecting samples.



5. Once things are set up, you can move the the 0 point and see the data broken out like this:



Let me know if I can elaborate or clarify any of these notes.

Deal57,
Thank you very very much.
I have confirmed all my setting,









And will keep seeking my problem on MJX SPI data.

robca wrote: I set very longcapture times, then manually stop the process when the right events are captured... there's no need to guess how much you need, when you stop capture the Logic software saves the file until that point

Trying to guess how many samples you need is super frustrating

That's a good idea, thanks!
I also follow Deal57's setting to set a trigger on clock channel,
it's perfect now.