element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Community Hub
Community Hub
Member's Forum Tools and techniques for documenting data captures
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Leaderboard
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Community Hub to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 11 replies
  • Subscribers 527 subscribers
  • Views 1733 views
  • Users 0 members are here
Related

Tools and techniques for documenting data captures

beacon_dave
beacon_dave over 3 years ago

What tools and techniques do community members use to document their data captures over those longer term projects ?

I've been working on a project on and off over the past couple years but I haven't yet found a good way to document data captures in such a way that they can be annotated and then the annotations updated at a later point in time as more information is found. It is getting to the point where we are now talking 100's of captures so looking for better ways of doing things to tidy up the existing documentation process.

For this specific project, most of the data has been captured in the field on a PicoScope USB scope and forwarded onto me, however I have found similar issues with other scopes. In this case the data being captured is mostly bidirectional serial data with Tx and Rx being captured on separate scope channels. The PicoScope software is currently decoding the serial data and displaying it under each trace. However in order to be able to read the decoded data, you have to 'zoom in' sufficiently with the timebase which then quickly results in a very small active window sliding back and forth over a much larger data capture.

For documentation however it would be more convenient to be able to take a screen shot of the full capture at a sufficient resolution such that you could quickly look at it outside of the scope software and compare it to previous captures, but the print options provided appear to limit you to printing a single page of the current view and even then it removes the serial decoding in the process. 

Currently to get a 'quick' overview for documentation it is a case of taking multiple screenshots and then stitching them together back into one wide image to view in a bitmap viewer. Even for relatively small captures this is quite time consuming.

Another approach might be to export the individual scope traces and serial decodes as CSV data then write some code to import and parse the 4 CSV files and combine them back into a single two channel waveform with decoded serial data and save it as something like SVG format to replicate what the scope display does. The advantage of this route is that it allows for additional processing of the serial decoded data and thus additional data annotations can be added automatically e.g. decoding the captured value and then displaying it as text for the human readable stuff, or using colours to highlight specific values of interest.

In either case, additional annotation tends to have to be done in packages which can work with the bitmap or vector graphics files, either editing them directly or by importing and overlaying on top of them on a separate layer.

Getting hardcopy out is another issue, especially if you find it easier to scribble notes on paper, so printing to a till roll type printer might be useful. I have seen some scopes that appear to be able to do that directly.

That sort of documents the general overview of the data where you get to see the activity, the timings between send and receive activity and the actual data transferred. But once you start to dig deeper into the data you ideally need to be able to work on the captured data in other ways. Some of it I've switched to WaveDrom where the exact timing is of less interest but it can be time consuming to extract the captured data and then create the mark-up and even then getting printouts can sometimes be problematic if not viewing on-line. It's also yet another application.

I guess it pays to choose your scope carefully and making sure that it can export captures in a wide range of formats from the outset.

However I'm interested generally in what other tools and techniques have been used in this area.

  • Sign in to reply
  • Cancel

Top Replies

  • javagoza
    javagoza 3 months ago +4
    I use plantuml a lot. You only need to download a java jar file and can execute it from the command line java -jar plantuml.jar sequenceDiagram.txt or use the online editor PlantUML Editor Timing…
  • beacon_dave
    beacon_dave over 3 years ago in reply to shabaz +2
    Hi Shabaz, Yes, I have been using that serial decode table export option extensively up until now. I export and parse in Python to extract the data values and then process them and create hex dumps.…
  • shabaz
    shabaz over 3 years ago in reply to beacon_dave +2
    I was just browsing sequence diagrams, and found a python library called seqdiag . It's easy to install ( pip install seqdiag ) and accepts input in a form like this: seqdiag { edge_length = 300;…
  • shabaz
    shabaz over 3 years ago

    Hi Dave,

    I think this is where subscription services like Tek Cloud could be useful, since they can be viewed/explored in detail there as I understand.

    I used a mix of methods like directly annotating the screenshots, and using WaveDrom or similar for DMX documentation here: /technologies/open-source-hardware/b/blog/posts/dmx-explained-dmx512-and-rs-485-protocol-detail-for-lighting-applications

    For spectrum analysis, the Rohde & Schwarz FPC1500 stores a lot of data in a format where it can be navigated just like as if the user was using a real spectrum analyzer, using viewer software, so even if you miss spotting some detail initially, you can always examine it later.

    Also, Tek scopes can capture waveforms for replaying or analyzing them, in a format I can't recall - I think it's CSV-like, with a few initial rows containing the 'scope configuration values in text form. You can import that into (say) Matlab, Python etc (Excel slows down a lot with large files).

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 3 years ago

    Just re-read your post, sorry I only had a brief amount of time before. 

    It's an interesting topic.

    On my 'scope, I have the option to see the serial decodes in a list which is timestamped from memory, so I think I can export those to a file too. I just took a look at Picoscope (just with the demo mode, no real data, and it has a listing capability too (lower pane in the screenshot below), and I believe export on that too:

    image

    However, I don't know if you also need other signals to be captured simultaneously too. I've not seen a solution to that, i.e. where you might have other signals that need timestamping in some way too, simultaneously with the serial decode.

    You could also have perhaps a custom solution, e.g. parse the decode file into a presentable format for viewing and analyzing. In the past, for software packet streams, I've created custom software to present it, I don't know if that could be something to consider. For instance, if I know the serial data is in a format with (say) a header and payload, then I could print each header and payload on a separate line, or in separate CSV columns etc. Even a graphical option can be helpful, e.g. automatically parsing and drawing ASCII ping-pong diagrams of the messaging and a timestamp printed against each line.

    If you're getting repeated captures then custom software to graphically show events could be handly too, since they can be overlaid to quickly see anomalies like late or missing messages. I once did something like that to display thousands of repeated sequences, on a single image, and you could click your cursor on a line and select the outlier, and instantly pull up detail on it. I did it a very long time ago, so I used MySQL at that time to store all the packets and events, and then graphically draw them with the x-axis being time, and y-axis showing events (it looks like slanted stick segments - I suggested patenting it but there was no interest at the time) and brute force line identification by searching every entry with a timestamp for that event in the approx region.

    Anyway, these are just some more thoughts that came to mind.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • beacon_dave
    beacon_dave over 3 years ago in reply to shabaz

    Hi Shabaz,

    Yes, I have been using that serial decode table export option extensively up until now. I export and parse in Python to extract the data values and then process them and create hex dumps.

    You have to export each serial decode as a separate CSV though so it is a multiple step process.

    You can also save the waveform to CSV as opposed to the proprietary PSDATA format however you get rather large files if you do so.

    One thought was to take all the separate CSV exports and use the timestamps to recreate the waveform plus serial decode in something like a SVG type format so as to either add additional annotations programmatically in code or to import it into another tool an add information there.

    It seems like a lot of work though just to more-or-less replicate what is on the screen in front of you.

    For people who have to do this all the time then I was expecting there to be a software tool that allows you to work with this sort of data in a more efficient manner to create technical documentation. A bit like the equivalent of Jupyter notebooks where you can create 'living' documents as it were.

    But at least if you have your data archived in a well known format you can start to bring it into other tools to do additional annotation work. It's also a lot quicker to view the likes of SVG files than to have to reload the scope capture into the likes of PicoScope every time, especially if you want to compare two or more captures at the same time.

    The ping-pong messaging diagrams are another area of interest. How to quickly extract the decoded serial data and timestamps in order to create the messaging diagrams without having to do it all manually from scratch each time.

    Also extracting parts of the data to get it into WaveDrom style diagrams to break apart  frames into register level type detail.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 3 years ago in reply to beacon_dave

    I was just browsing sequence diagrams, and found a python library called seqdiag. It's easy to install (pip install seqdiag) and accepts input in a form like this:

    seqdiag {
      edge_length = 300; 
       === Event: Button Press ===
      A -> B [label = "01 01 00 [START] Time=11:00:57.045"];
      A <- B [label = "00 [OK] Time = 11:00:57.509", note = "CRC ERROR!"];
    
      A -> B [label = "02 05 00 [HELLO] Time = 11:00:58:110"];
      A <- B [label = "02 05 00 [HELLO] Time = 11:00.58. 143"];
    
      }
      

    And can output SVG like this:

    image

    There;s an online version where any example text can be pasted in, and it will generate in the browser. 

    Perhaps seqdiag or similar types of libraries can become part of custom solutions. Anyway, maybe it's completely not what you need! but figured it's worth just mentioning in case it helps even for unrelated stuff. I can see myself using such a tool in future too. 

    Another tool more geared for navigating through large data captures is of course WireShark, and perhaps a custom plugin could be used for your needs (and WireShark can generate approximately such type of diagram), however I've never written a plugin and I have no idea how easy or hard it could be.

    I've always wanted to learn though, because it feels like a useful skill to have, since there are a million-and-one uses for WireShark.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • beacon_dave
    beacon_dave over 3 years ago in reply to shabaz

    Hi Shabaz,

    That seqdiag library looks like it could be really useful. The ability to add notes in addition to labels is one of the type of things that is currently missing from my workflow. I've tried in the past to add notes/call-outs in PDF documents but it can quickly get messy if you are annotating a hex dump.

    It's a bit like a step back to the old days of word processing though where you had to manually insert the mark-up tags throughout your plaintext document.

    I think WireShark could be useful if you know the protocol up-front, but in my case I'm having to reverse-engineer it all from scratch.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 3 years ago in reply to beacon_dave

    Hi Dave,

    I see. Depending on what kinds of exploration you wish to do, it may be worth putting every packet into a database, along with any metadata you have like direction, timestamp, and session or transaction stuff and so on. It could be any traditional database, e.g. mySQL or PostgreSQL, and then you've got the ability to manually or programmatically (e.g. Python) search and view content, and even chart things like delay between messages on multiple runs of the systems. 

    I did something similar for at least tens of thousands of sets of messages, although in my case they were in a log file, so I wrote code to go through any log file, and automatically populate the table in the database. Because everything is timestamped, I could repeat for additional log files whenever I had them, so I didn't need to erase the table if I wanted to keep information across many days for trying to spot an anomaly.

    Storage is cheap : ) so although it seems excessive to use a database for serial capture packets, I think it's perhaps a reasonable approach, since you don't have to then solve all processing and data presentation/annotation problems on day 1. Anyone can then work with the data and generate their own reports, since there must be plenty of tools out there for viewing database contents in different ways (or use Python).

    Any annotations/notes can be an additional field in the database. And a separate table with sessions for instance, with their own notes.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • Workshopshed
    Workshopshed 8 months ago

    I wonder if a timeseries database might be one tool to help with this. InfluxDb used to be the front runner but I've heard that  https://prometheus.io/ is a plugin replacement. 

    For display grafana is easy to use and seems to have the ability to add annotations.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • javagoza
    javagoza 3 months ago

    I use plantuml a lot. You only need to download a java jar file and can execute it from the command line

    java -jar plantuml.jar sequenceDiagram.txt

    or use the online editor PlantUML Editor

    Timing Diagrams

    image

    Sequence Diagrams

    image

    • Cancel
    • Vote Up +4 Vote Down
    • Sign in to reply
    • Cancel
  • michaelkellett
    michaelkellett 3 months ago

    Part of the problem is the shear size of the data sets and the sparsity of the information in them.

    Logic analysers often compress the long intervals between the active parts of records and have decent tools to skip from one to the next.

    (Aldec's Active HDL waveform viewer is excellent in this respect (its not a data capture thing but part of an VHDL/Verilog simulator)).

    All the good tools I know for examining huge sparse data sets don't have any way of printing it or sharing it with third parties other than sharing both tool and data. Active HDL often generates multi Gbyte simulation files.

    Scopes offer segmented acquisition as a way of acquiring sparse data, but I find it's never quite as good as I hoped and that triggering is a problem.

    Some scopes allow you to annotate on screen.

    Your choice of Picoscope is (IMO) as good as it gets - I find it easier to use than any of the expensive scopes I've owned or tried and you can get away with a pretty basic Pico for sub MHz serial stuff. The software is the same on £500 or £10k Picoscope.

    You might like a logic analyser (I use the ZeroPlus LapCPro https://www.zeroplus.com.tw/logic-analyzer_en/products.php?pdn=1&product_id=767 ) - I'm not sure if you can use the software for free to examine third party captured data.

    It would be a lot of work to write something good  and although I would be prepared to buy something off the shelf its not enough of an issue (for me) to make it worth the effort of a DIY solution.

    MK

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • javagoza
    javagoza 3 months ago

    I've occasionally used this software from Sigrok PulseView - sigrok, which supports many low-end analyzers and dataloggers and allows data import PulseView User Manual.  There's extensive community support with analyzers for many popular protocols. Protocol decoders - sigrok

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube