Skip to content
Andrey Pozdnyakov edited this page May 24, 2017 · 9 revisions

What is this

Before we got functioning hexagon boards the idea was to generate fake data using RPI modules, send it over the network switch and receive by our DAQ. The codes in ./sandbox attempt to do that. The idea is to start a simple TCP server on RPI board which can accept commands (start/stop) and send data via TCP socket. On the side of euDAQ, the RpiTestProducer.cxx is responsible to connect to the server and get data from it.

Test TCP server scripts

This should work on any OS with python installed.

  • In one terminal window run a script ./fakeDataGeneratorNew.py 32 (in scripts directory). It starts the TCP server which will wait for commands.
  • From another terminal do: ./pokeTCP.py 127.0.0.1 ANYTEXT. Observe what happens in both windows.
  • Now, from the client window run: ./pokeTCP.py 127.0.0.1 START_RUN. This will make the server to send data.
  • Then do ./pokeTCP.py 127.0.0.1 STOP_RUN to stop it.
  • Play with it.

Rpi Test producer

It implements low-level socket connections to the TCP server, sends start/stop commands and receives the data. Here is how to start it:

  • Keep the fakeDataGeneratorNew running in one of the terminals.
  • From another terminal, go to the root of eudaq and execute: ./STARTRUN testrpi. This will start the producer.
  • Load config file from sandbox/conf/RpiTestConfig.conf
  • Now, you can Start and Stop runs. Observe the messages in LogCollector and other windows.
  • fakeDataGeneratorNew picks up a file from local directory and submits it over to euDAQ. The files for this test could be found on svhgcal01 computer at /disk2_2TB/data/
  • Online Monitor is useless for this particular test. See RpiProducer wiki page for a more useful test.

Useful commands

  • Check if a port is open on remote host: nc -w $TIMEOUT_SECONDS -v $HOST $PORT </dev/null; echo $?
    For example: nc -w 2 -v pcncu21.cern.ch 80 </dev/null; echo $?

To do list:

  • Write raw data to a file.
  • Test with realistic dataflow rate.
  • Make the format of the fake data more realistic. Use 32 bit words as going to come via IPbus.

Other plans (outdated):

  • Need to switch to UDP instead of TCP (since IPBus we plan to use is based on UDP). This should be straightforward in the low-level implementation, but not clear about high level (there is no UDPClient in eudaq).
    • This is no longer the plan. We are going to use IPbus in the real data-taking.
      • UPD: since the IPbus was not ready for the first test beam, the RpiProducer was in fact used for data-taking. The mentioned UDP was implemented for data transferring. See RpiProducer wiki page for more details.
  • Instead of low level sockets one should be able to use TCPClient object (class in eudaq), which may simplify things.
    • This is no longer the plan. We are going to use IPbus in the real data-taking.
  • Start remote TCP server on configure (Tanmay has done similar thing in his codes, just need to propagate here.)
    • This is no longer the plan. We are going to use IPbus in the real data-taking.
  • Think of how to combine data from multiple sources.
    • This is being done by Arnaud in IPBusTest producer (using boost threads)

Useful material on this topic: