Ray stopped by to touch base on the project status. We're hoping the ME students will get the wall/ceiling mounting brackets installed at CLC before the end of next week, and also get the electronics boards mounted to the chassis before the Senior Design Fair.
Juan is here, and I suggested he work on the Acer instead of the VirtualBox since it is faster, and loaned him my 8GB USB flash drive so he could transfer the files. He is doing that.
Aarmondas is here, maybe I can start taking him through some things that need to be done on the Python code. I re-shared the Server Code folder with him and it is downloading onto his laptop. He's also installing Python v.3.1.4.
I saw some glitches in the 300 MHz pulseform-capture system when I tested it the other day; I wanted to work on that today (or soon).
Some things to do (coming up) on the server code:
Aha, forgot to add support for the LOST_PULSES message. Did that (skeleton at least).
OK, we're still getting the glitches in the 300 MHz data. I had an idea the other day to try to fix this, which was to add a synchronizer chain on the handshake return in pulse_cap. Let me do that...
OK, I added a 4-stage synchronizer chain to the hs_cons inputs to both se_pulse_cap_56.vhd and se_pulse_cap_tsedge_56.vhd. Hope 4 stages is enough! We'll see. Note: Adding this synchronizer increases slightly the minimum "dead time" between separate pulses we can detect on a single input channel. At 500 MHz, the increase will be by 4*(2 ns) = 8 ns. However, it is already quite a bit larger than this, as cs_combine already takes a few 20 ns cycles to return its handshake.
Speed of new design: 587.89 MHz (high-speed components only); 353.23 MHz (whole design).
The change seems to have done the trick WRT eliminating the glitches. The data we're collecting at 300 MHz looks clean now.
Aarmondas is looking at a couple of possible solutions for the database: SQLlib (in Python), vs. MySQL. I told him he should consider which approaches are most flexible in terms of allowing us to actively query the database from another process while the main server is still writing data to the database. A separate database server process might be needed to do this (if we don't want to integrate a SQL server into the main server app).
Aarmondas is here, maybe I can start taking him through some things that need to be done on the Python code. I re-shared the Server Code folder with him and it is downloading onto his laptop. He's also installing Python v.3.1.4.
I saw some glitches in the 300 MHz pulseform-capture system when I tested it the other day; I wanted to work on that today (or soon).
Some things to do (coming up) on the server code:
- Put FEDM messages into data structures; publish them using the Publisher interface.
- Finish the startup sequence coding (automatically start CTU after FEDM is ready)
- Write some simple early visualization modules - e.g. graphical display of CTU time data
Aha, forgot to add support for the LOST_PULSES message. Did that (skeleton at least).
OK, we're still getting the glitches in the 300 MHz data. I had an idea the other day to try to fix this, which was to add a synchronizer chain on the handshake return in pulse_cap. Let me do that...
OK, I added a 4-stage synchronizer chain to the hs_cons inputs to both se_pulse_cap_56.vhd and se_pulse_cap_tsedge_56.vhd. Hope 4 stages is enough! We'll see. Note: Adding this synchronizer increases slightly the minimum "dead time" between separate pulses we can detect on a single input channel. At 500 MHz, the increase will be by 4*(2 ns) = 8 ns. However, it is already quite a bit larger than this, as cs_combine already takes a few 20 ns cycles to return its handshake.
Speed of new design: 587.89 MHz (high-speed components only); 353.23 MHz (whole design).
The change seems to have done the trick WRT eliminating the glitches. The data we're collecting at 300 MHz looks clean now.
Aarmondas is looking at a couple of possible solutions for the database: SQLlib (in Python), vs. MySQL. I told him he should consider which approaches are most flexible in terms of allowing us to actively query the database from another process while the main server is still writing data to the database. A separate database server process might be needed to do this (if we don't want to integrate a SQL server into the main server app).
No comments:
Post a Comment