<d1b2>
<ledude0001> For this source code, my device responds to :TRIG:MODE? with EDGE. However I use Uart and it is too slow to even recieve teh command. cpp auto reply = Trim(m_transport->SendCommandQueuedWithReply(":TRIG:MODE?")); if(reply == "EDGE") PullEdgeTrigger(); Here is what I see in the logs as Warning: Unknown trigger type ":TRIG:MODE?" Warning: Unknown trigger type ":TRIG:MODE?" Warning: Unknown trigger type "DGE" Warning: Unknown trigger
<d1b2>
type ":TRIG:MODE?" Warning: Unknown trigger type ":TRIG:MODE?" Warning: Unknown trigger type "GE" Warning: Unknown trigger type ":TRIG:MODE?" Warning: Unknown trigger type ":TRIG:MODE?" Warning: Unknown trigger type "DGE" As you can see, the client sends requests to quickly and the reply "EDGE" never gets fully recieved in time how do I solve this ? 😓
<d1b2>
<ledude0001> I used UART since I don't have an ethernet cable near me
<d1b2>
<azonenberg> Dropping traffic during receive is concerning because the PC should be much faster than your firmware
<d1b2>
<ledude0001> would ERROR: SCPITransport::FlushRXBuffer is unimplemented be the cause?
<d1b2>
<azonenberg> Honeslty i'd try turning on hardware flow control first
<d1b2>
<azonenberg> And see if that solves your problem
<d1b2>
<azonenberg> rather than adding random hard coded delays. EnableRateLimiting is a last-resort workaround for buggy third party firmware you don't have access to fix properly
<d1b2>
<azonenberg> But also random partially received messages is confusing to me because there's no way "EDGE" is long enough to overflow the RX buffer on the PC
<d1b2>
<azonenberg> and seeing :TRIG:MODE echoed back by the device is weird
<d1b2>
<ledude0001> I think my uart client sends it back for some reason 😲
<d1b2>
<ledude0001> where please?
<d1b2>
<azonenberg> What OS is this?
<d1b2>
<azonenberg> Linux? (I forget if we even implemented the uart transport for windows yet)
<d1b2>
<ledude0001> arch linux btw yes
<d1b2>
<azonenberg> https://man7.org/linux/man-pages/man1/stty.1.html should be helpful there. As of now, the uart transport sets baud rate but doesnt touch any other settings (since that's so hardware specific)
<d1b2>
<azonenberg> "crtscts" is the option to enable hardware flow control (you'll need this supported in your firmware as well).
<d1b2>
<azonenberg> then "raw" will turn off a bunch of processing and "-echo" turns off echoing of traffic you send
<d1b2>
<azonenberg> you probably want at least raw -echo for talking to a scope and flow control may or may not be helpful depending on where the bottleneck is
<d1b2>
<azonenberg> But realistically speaking hanging a scope off a uart is going to be absurdly slow and should be a last resort 🙂
<d1b2>
<azonenberg> like, you can get away with using a uart for things like a power supply or multimeter where the amount of data transferred is tiny
<d1b2>
<azonenberg> but with a scope even a modest 10K point waveform at 8 bits per sample is 80 kbits, after start/stop bits 100 kbits, so you're looking at almost a second of transfer time at 115.2 kbps
<d1b2>
<azonenberg> so ~1 WFM/s best case
<d1b2>
<ledude0001> I just want my scope to work for now 😢
<d1b2>
<azonenberg> Fair enough
<d1b2>
<ledude0001> choosed a hard first FPGA project xD
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> If you're doing a new hardware revision and want low effort but way more performance, look at some of the usb parallel fifo stuff from FTDI or their competitors
<d1b2>
<ledude0001> ok thanks a lot!
<d1b2>
<azonenberg> https://ftdichip.com/products/ft600q-b/ for example is usb3 to a 16-bit parallel fifo interface that should be easy to use from fpga and claims 400 MB/s transfer rates
<d1b2>
<azonenberg> We dont have a transport layer made for them yet, i'm not sure what the host side API looks like but FTDI does provide libraries for talking to them
<d1b2>
<azonenberg> out of curiosity are you with the same group as Kerr or is this a separate project?
<d1b2>
<ledude0001> wow the schematic is available too
<d1b2>
<ledude0001> thx
<d1b2>
<benny2366> jhea curios if you can beat digilent in making something more reliable than them! good luck
<d1b2>
<ledude0001> if they are on discord can you @mention them 😅
<d1b2>
<azonenberg> They're on IRC, it's bridged to this channel
<azonenberg>
Kerr: ^
flinner has joined #scopehal
flinner is now known as ledude
<ledude>
Kerr: would like to chat about scope design for a bit, can I msg you?
<azonenberg>
Scope hardware design is on topic for the main channel. You're far from the only people here who want to design their only scope
<azonenberg>
(just the only two i know of doing it specifically as a class project)
<azonenberg>
their own*
<ledude>
nice !!
<azonenberg>
My dreams are bigger (think AD9213 and UltraScale+ FPGA and DIMM of DDR4 per channel, 2 GHz BW, 10 Gsps, 12 bit)
<azonenberg>
as well as a 16 bit 100 Msps 28 channel low speed scope
<ledude>
whao
<azonenberg>
Both are high level block diagrams only at this point, i've had my hands full with other stuff but hope to spend some time on actual circuit design maybe over the summer
<ledude>
xDD I aim to make <50$ scope+logic analyzer + func gen
<azonenberg>
Yeah. Different market segment :)
<azonenberg>
I want to compete with midrange gear from the big vendors
<azonenberg>
anyway point is if you want to bounce ideas on adc selection or frontend design off people
<ledude>
I hope to work on high speed designs after graduation
<azonenberg>
odds are there half a dozen folks in the channel who have looked at and maybe used those same parts :p
<ledude>
nice! is the channel on irc or discord?
<azonenberg>
both, thats the point of the bridge
<azonenberg>
as long as the bridge is working (it does go down occasionally) you can message on either side and everyone sees it
<azonenberg>
you just can't PM from one to the other
<_whitenotifier-5>
[scopehal] azonenberg c9f2e93 - Initial ActionProvider integration in PAMEdgeDetector
<_whitenotifier-7>
[scopehal] azonenberg bae3af2 - PAMEdgeDetector: don't auto-threshold every single waveform, only the first waveform and when the user asks for it explicitly
<d1b2>
<azonenberg> @hansemro what's the state of your siglent bin import filter again? are you planning to finish taht?
<d1b2>
<azonenberg> it'd be nice to have it done and merged
<d1b2>
<darius0949> I had this with my ancient tek, I munged the code
<_whitenotifier-5>
[scopehal-docs] azonenberg de7c778 - Renamed revision file to intro to better reflect its actual content. Moved "documentation conventions" section to beginning of document