| Products > Test Equipment |
| New Scope Demoboard from Batronix |
| << < (24/65) > >> |
| Andre77:
--- Quote from: KungFuJosh on June 11, 2023, 01:48:16 am ---I got my board in yesterday, and I was thinking about trying it out next week. Then I remembered I only know a few words in German (some aren't even swears!). Maybe I'll google translate it with my phone lol. --- End quote --- The translation is complete, you can download the English manual using the following link: https://www.batronix.com/files/Batronix/MSO-Demoboard/Batronix-MSO-demo-board-web-EN.pdf Furthermore, the Demo Board website is now accessible in English as well. https://www.batronix.com/shop/demoboards/Batronix-MSO-Demo-Board.html |
| RAPo:
Great! My board came in today. |
| 2N3055:
--- Quote from: Martin72 on June 07, 2023, 11:18:30 pm ---This is way more stable than mine, I´ll make a short clip in the next days. And: As I mentioned before, my siglent decode it correctly, you can see it best when in stop mode. --- End quote --- Board came today... I confirm SPI data coming of the board is jittery... Also there is no deterministic timing between CS and clock and rest of data. But it is not in violation of SPI protocol. Decodes fine. To get stable trigger I did nothing special but triggered on clock with holdoff or SPI protocol trigger that will align data decoded to clock. That will give stable left edge. Rest of packages and signals will not align or overlap because they differ in position and timing... If I set trigger for just one SPI packet data type (for instance MOSI 52 6F hex) i get same packet that does not have uniform timing. SPI is definitely bit banged and interrupts are, well, interrupting... |
| Martin72:
--- Quote ---But it is not in violation of SPI protocol. Decodes fine. --- End quote --- Yepp, that was also no problem here. Today I´ve tried again on a lecroy(WR9054) and got it reasonably stable (timebase 200µs/div, 200kbit/s) with timeout appx 7.4µs("pause" between the clocks), last trigger. |
| Andre77:
About the jittering between data words: The microcontroller on the demo board has different interrupt sources with different priority. The interrupt for the "function generator" DAC is treated with the highest priority. There, the 1-data word buffer must be refilled in time before the next data word is output. The interface interrupts have a lower priority level than the DAC. Different time spans can lie between two data words. This results in the jittering that looks choppy but also more realistic like a real microcontroller application. This type of jitter between data words has no influence on correct data transmission/decoding. |
| Navigation |
| Message Index |
| Next page |
| Previous page |