Thanks Gerhard for the reply. I am only picking one approach due to constraints on my own time, not discarding arbitrarily. I have already investigated the file format, it has some limitations. I also prefer direct connection over file parsing as I want remote control. Happy to add info to the wiki on all of this though, so I'll drop by the IRC to get an account.
Regarding the communication, taking a look at the hameg-hmo driver I now see that comms are abstracted for the SCPI driver. That driver seems to be the example I was looking for. Unfortunately the commands for the 16700 are not a standardised format like SCPI, they're textual and described here <https://literature.cdn.keysight.com/litweb/pdf/5988-6223EN.pdf>. I'm currently digging for info on the various Comms APIs. I'll move my questions over to the IRC. On Tue, 14 Jan 2020, 19:55 Gerhard Sittig, <gerhard.sit...@gmx.net> wrote: > On Thu, 2020-01-09 at 22:15 +0000, Marcus Bannerman wrote: > > > > I'm keen to extend sigrok to support the Agilent 16700 series > > of logic analyzer mainframes and I'm looking for a bit of > > support where best to start. > > > > [ ... ] > > > > I think there's two approaches to the implementation, either > > (1) learn to parse the file format that the systems use to > > export to a desktop pc, or (2) use the remote programming > > interface over the network. I'd prefer the latter as I'd like > > to be able to control the system via pulseview. > > What makes you feel that these approaches would be strictly > alternative, and only one of them could get implemented? :) > > Sure, one of them is more appealing to you, but that does not > exclude the other as a potential intermediate step to get there. > Experience from other device drivers suggests that vendors do > re-use details from communication protocols in file formats and > the other way around. You may learn something that's re-usable in > the process. > > Can't speak more specifically (having neither access to the > device, nor knowing their physical attachment nor communication > protocol nor the software's file format). But: Pick one approach > that you think is easier to achieve for now, but don't discard > the other just because one of them exists, or is about to appear > at some time in the future. Whatever increases your chances of > exchanging data with that system is good, is it not? Even if you > achieve remote control of live sessions, you or other users still > may want to import previously recoded captures without repeating > the setup (if at all possible). > > > Can you tell me if there's any work on agilent/keysight's file > > format already underway? > > I'm not aware of any. You may consider adding an item to the wiki > page, the list of file formats. To raise awareness. Also consider > creating a wiki page for the file format itself, to make details > available which anyone would need to implement the support. > > > Also, can you point me to a good example of a driver for a MSO > > or something similar using a network connection? The agilent > > just uses telnet/text so nothing complicated is needed there. I > > couldn't find SCPI-based drivers in my quick search which > > should also be a similar implementation. > > The sigrok project provides abstractions for several layers of > communicating to devices. Which means that you may not strictly > have to look for specific examples of an ethernet connected logic > analyzer or scope (which reduces the set of samples that you can > find). Consider the option to "communicate a stream" of requests > and responses which "just happens" to be of serial nature and get > transported via ethernet by coincidence, while the physical > transport might as well be any other medium. Again, not being > familiar with that device of yours and its protocol, I cannot be > more specific. > > > As a general rule of thumb, you may find more developers and see > faster turnarounds on questions and answers of that kind in IRC > than the ML. And IRC is also where you can get a wiki account to > improve and extend available documentation, regardless of whether > you plan or are able to implement a driver or input module. Any > help is appreciated when it results in an improvement for other > users. > > > virtually yours > Gerhard Sittig > -- > If you don't understand or are scared by any of the above > ask your parents or an adult to help you. > > > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel >
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
