| Products > Test Equipment |
| Pocket-Sized 6 GHz 1 TS/s ET Scope |
| << < (59/107) > >> |
| joeqsmith:
Thanks. This makes sense. You may want to consider creating a forum for your products that you could direct customers to from your website. The groups.io reflector seems to be popular. As sales grow, you may also want to start thinking about putting a FAQ together. |
| joeqsmith:
The software I put together to test your scope is pretty barbaric. Send a command, wait for a response. Because your protocol is not consistent for all messages, I have unique handlers for the types. It was just a brute force to try some things out and not meant as a solid platform to build on. If I were to write something for it, I wonder how your firmware handles say back to back commands? How deep is your message queue? If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it? Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent? Just thinking how I would structure the software. I wonder if you came up with a better protocol, would you be able to change it this late in the game? For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF? Adding a CRC or other error checking/correction.... For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it. Maybe you feel it is good enough to build on? |
| SJL-Instruments:
--- Quote from: joeqsmith on February 09, 2024, 03:39:04 pm ---You may want to consider creating a forum for your products that you could direct customers to from your website. The groups.io reflector seems to be popular. As sales grow, you may also want to start thinking about putting a FAQ together. --- End quote --- Thanks, these are both good ideas. We do plan on doing this once as our userbase expands. For the time being, we are following up with users individually (mostly via email), and they generally appreciate the one-on-one communication. Our focus for now is user support and software development. We think our current communication model works well in these early stages, but the tradeoffs will change as sales increase. (A forum enables users to help each other and share knowledge, but this is most useful above some critical number of participants.) --- Quote from: joeqsmith on February 09, 2024, 08:00:48 pm ---The software I put together to test your scope is pretty barbaric. Send a command, wait for a response. Because your protocol is not consistent for all messages, I have unique handlers for the types. It was just a brute force to try some things out and not meant as a solid platform to build on. If I were to write something for it, I wonder how your firmware handles say back to back commands? How deep is your message queue? If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it? Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent? Just thinking how I would structure the software. I wonder if you came up with a better protocol, would you be able to change it this late in the game? For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF? Adding a CRC or other error checking/correction.... For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it. Maybe you feel it is good enough to build on? --- End quote --- The current serial interface is designed to be simple to use as possible. We think the current specifications do give us enough leeway in the future. If we were to add CRCs, for example, we would have a command to enable them. We also have a command schema (anything starting with #) reserved for future use. We will never break backwards compatibility - that's just asking for trouble. For terminators, we use CRLF everywhere we can, for ease of use from an interactive terminal. For binary responses, a CRLF is too likely to appear in the data. The SJLI "terminator" is less likely to appear. Of course, it may still happen (1 in 4 billion chance), so in our software we read based on the expected length of the message. (As to why it's there at all: for some users, it might be acceptable to look for the SJLI and discard responses with the wrong length, which is much easier to implement.) There is currently not a message queue, to minimize bugs and edge cases (e.g. changing the parameters during collection, as you've mentioned). If it becomes necessary, we can add one without breaking any existing user programs. Currently, the firmware ignores any command sent before the previous response is read. A message queue would process each command in order (so, still no issues with parameter changes during collection). |
| joeqsmith:
Simple is fine as long as it is robust. I have completely restructured my test code which has turned up an odd behavior that I would like to understand. I send a CAL command and wait for the scope to respond with the OK CAL. I then immediately send the Delay command. What I am seeing is the scope will respond with a Delay underflow -inf. I would assume that as soon as the scope sends the OK CAL, it is ready to take the next command but it doesn't appear that is always the case. It never gives me this warning except when performed right after a CAL. If I get this underflow and immediately resend the D command, it never fails that I have seen, on the second attempt. *** If after receiving the OK CAL, I wait an additional 50ms for the scope to do what ever it is doing, then send the D command, it never seems to throw the underflow warning. It seems that OK doesn't really mean it's OK when it comes to the calibration. |
| joeqsmith:
In anticipation of the new power user mode, I trimmed my delay line to center around the 8ns start of collection. Time to remeasure it on the VNA. |
| Navigation |
| Message Index |
| Next page |
| Previous page |