Electronics > Projects, Designs, and Technical Stuff
Measuring time span very precise
<< < (13/16) > >>
hamster_nz:

--- Quote from: HendriXML on September 07, 2019, 05:37:51 pm ---
--- Quote from: hamster_nz on September 07, 2019, 12:12:27 am ---Simple, accurate, and cheap. Borrow an FPGA dev board

--- End quote ---
FPGA will eventually be used in the projects, but for now a bit too soon.  :-+

--- End quote ---

Please reconsider... as an example of how this is the perfect domain for this tool, here it the complete timing module, which will be accurate to maybe +/-20ns with a 100MHz clock (pretty much standard for an FPGA).

You just need outside code to filter the inputs (synchronise them to the system clock using a few flipflips, and maybe de-glitch the start and end signals to prevent double triggering):


--- Code: ---library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity timer is
    Port ( clk           : in  STD_LOGIC;
           -- control inputs
           start_signal  : in  STD_LOGIC;
           end_signal    : in  STD_LOGIC;
           rearm_signal  : in  STD_LOGIC;
           -- statue signals
           armed         : out std_logic                      := '0';
           running       : out std_logic                      := '0';
           -- counter outputs
           count         : out STD_LOGIC_VECTOR (39 downto 0) := (others => '0');
           new_count     : out STD_LOGIC                      := '0');
end timer;

architecture Behavioral of timer is
   signal counter : unsigned(39 downto 0) := (others => '0');
begin

process(clk)
   begin
      if rising_edge(clk) then
         new_count <= '0';   -- default for the new count
         armed     <= '0';   -- default for the 'armed' status LED
         running   <= '0';   -- default for the 'running' status LED
         if counter = 0 then
            armed <= '1';     -- we are armed!
            if start_signal = '1' then
               counter <= counter +1;  -- We are triggered!
            end if;
         else -- if we are counting
            if end_signal = '1' then 
               -- time to stop and output the new count
               count     <= std_logic_vector(counter);
               new_count <= '1';
               counter   <= (others => '0');
            elsif rearm_signal = '1' then 
               -- reset into the 'armed' state
               counter   <= (others => '0');
            else
               -- keep on counting as the timer is running
               running <= '1';
               counter <= counter +1;
            end if;
         end if;
      end if;
   end process;
end Behavioral;

--- End code ---

If you send that 40-bit "counter" to the AVR when new_count is '1' (most likely as ASCII hex). your problem is fixed. Far better than these "angels dancing on the head of a H/W timer's IRQ latency" issues.
iMo:
The jump into the FPGA world is for most ..duino users a difficult exercise. It is not only about the verilog but the entire infrastructure (boards, programmers, tool chain, etc) you have to master.

Even I've been driving the TDC7200 off an FPGA (start/stop TOF for my reciprocal counter), wiring it to an ..duino is matter of say 100 minutes (14pins smd, SPI interface). The arduino library is there, what you need is an external source of up to 10MHz for the TDC7200 calibration (the chip is 3.3V). And the resolution is 55ps with 35ps stddev in two modes (upt to 500ns and up to 8ms). So no need to mess with FPGAs, and you get a tool comparable with $10k HP rigs..
HendriXML:
Thanks again for the responses.

FPGA's are not in my comfort zone. If I use a component and scripts I only do so if I understand them well, or in the process of learning them. I don't like to copy 'n paste stuff.

I'm now going trough the elaborate post of Ian together with a good image of the Mega 2560 board, to figure out which traces/components have a role.

Before the mod is ordered/finished I'll off course use the resonator that is on board. Experimenting with a little oled display to show the measured speed. I also need to invert the signal coming from the gates (I guess). It is a comparator pull down signal when something crosses the beam.

What I like about this exercise is:
"Building" a high freq accurate clock signal
Modding the board, that is one step towards lower level interaction with the AVR. Seeing it as a component and not only as a module (together with the board).
Being already familiar with IDE and stuff. So that part won't be too difficult.
HendriXML:
I've just started, but it might be interesting to show what's standard on the board. (I also haven't checked the powerlines yet..)

I think it's now driven by the resonator (AG) near R14.
HendriXML:

--- Quote from: magic on September 09, 2019, 05:57:05 am ---By the way, contrary to the datasheet, my experience shows that 3.3V clocks drive 5V AVRs with no problem.

--- End quote ---
I think I might try that as well.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod