Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Matom

Pages: [1] 2
1
Software Dev / Re: Monitoring value on IO trigger
« on: August 09, 2018, 08:08:52 AM »
Okay, thank you very much.

The answer might be the same to the following question, but is there a way to access the DAC?

I see some mentioning of io1DAC and io2DAC, but I cant find the exact address. So far we have tried to read from map_base+offset but the values there are always the same. I would really like to read an analog signal somehow. 

Do you have any suggestions?

2
Chronos User Discussion / Re: NTP for precise timing
« on: August 03, 2018, 07:51:50 AM »
Thank you both for the answers.

NiNeff, do you have experience with the delay/accuracy with this method?

3
Software Dev / Monitoring value on IO trigger
« on: August 02, 2018, 05:36:22 AM »
Hi Krontech,

Is there a way to monitor the value on the trigger inputs in the software?

I would like to constantly monitor the value (low/high or 0/1) on the trigger inputs, like you can do on e.g. a GPIO pin. The idea is to send this value to a pixel on the image, thereby knowing if the given trigger input was low/high during that specific frame.

Cheers,
Maja

4
Chronos User Discussion / NTP for precise timing
« on: August 01, 2018, 12:22:21 AM »
Dear All,

I am using the camera for scientific purposes and I need precise timing. Ideally I would like to install ntp (network time protocol) and use it to synchronize the camera time to my computer which is connected to a GPS. I am trying to find a ntp package already compiled for the camera processor type (armv7l), but so far, no luck.

Do any of you have experience with this or other methods for precise timing on the camera?

Cheers, Maja

5
Software Dev / Re: Deploying camApp from Qt Creator
« on: June 13, 2018, 09:09:11 AM »
I also timed the routine without including my algorithm and in this case the cpu-time was around 2 seconds for 1000 frames, whereas the real time was still 16 seconds. Therefore, I think that there must be a delay or a set frame-rate somewhere. Maybe in the OMX files? I just can't seem to find the one that does the trick.

6
Software Dev / Re: Deploying camApp from Qt Creator
« on: June 06, 2018, 12:54:21 AM »
Dear David,

Thank you,  I'll try that.

I'm working in the VIL_ClientCbFilledBufferDone function. Here I do a bit of image analysis on each buffer, before it is passed on in the code. My algorithm is very light and is not the limiting factor when is comes to processing time. I have timed the function using clock() and time() and I can see that the CPU time (from clock()) is much lower (8 seconds to process 1000 frames) than the actual time (16 seconds for 1000 frames). The 16 seconds make me think that there is a value of 60 fps set somewhere in the code, maybe because the buffer is used display on the LCD. I don't use the display, but just want as many frames as possible to be processed in order to catch events of a few ms duration. I hope this makes sense ;)

Cheers,
Maja


7
Software Dev / Re: Deploying camApp from Qt Creator
« on: June 05, 2018, 01:46:02 AM »
Dear David,

I am starting to get problems that I did't have before. I have had to restore the microSD card 3 times within a week (when I was working out of the qt folder before, this only happened 1 time in 3 months). It happens when I work in Qt for a while and keep updating the camApp. Once in a while a connection error happens and I can't access the camera with ssh or Qt and a hard reboot is the only option. However the reboot can't open the camApp, so I have to restore the SD card. Is there a way to avoid this? If not, I can live with it, because I am almost done with the trigger.

However, I have another question:
There is a big difference between the CPU time and the real time of my trigger function i video.cpp. My guess is that there is a frame-rate set or delay/sleep/wait somewhere in the code that limits the frame-rate. Where is this?  I have changed the definition of MAX_LIVE_FRAMERATE in camera.h but this does not change it.

Thank you in advance, Maja.

8
Software Dev / Re: Deploying camApp from Qt Creator
« on: June 04, 2018, 08:51:10 AM »
Thank you David, I just backed up the original app, and so far there are  no problems.

9
Software Dev / Re: Deploying camApp from Qt Creator
« on: June 01, 2018, 11:37:05 PM »
Hi Again :)

After updating my computer (and restoring the camera because it wouldn't boot), QT is deploying the camApp that I'm working on directly to the /opt/camera folder. This seems to cause a lot of problems for me and I have had to restore the camera several times. The qt folder that the modified camApp was normally deployed to is gone. I have tried to make a directory myself and use it as working directory in QT but it doesn't work. Do you have any suggestions? How should QT be configured to make sure that I don't overwrite the original version of the camApp?

Thanks in advance !

10
Software Dev / Re: Deploying camApp from Qt Creator
« on: May 21, 2018, 11:05:41 PM »
Hi BiduleOhm,

What type of hardware trigger are you thinking of? A photodiode?

We will use the camera remotely (from a different country) and therefore want to avoid as many additional part as possible. With a software trigger we can easily adjust it from home with remote desktop. In addition we want to be sure that the camera only triggers on the right type of events and events that are luminous enough for the Chronos' sensitivity.

These are the main reasons for an internal software trigger. However, I am very happy to get advice and new ideas.

11
Software Dev / Re: Deploying camApp from Qt Creator
« on: May 19, 2018, 11:06:14 PM »
Thank you for the input :) The display would be nice to turn of anyway, to avoid light leakage (we will shoot in a very dark environment). Is it possible?

And yes, I am currently trying to improve the algorithm, however it still cannot trigger on light pulses that are shorter than 50 ms.

Regarding an external led or camera as trigger, this is our plan B, but ideally everything should be internal in the Chronos.

Yes, in our research (lightning) such a trigger would be a great addition. If I manage to develop something that works, I will be happy to share ideas with you.

12
Software Dev / Re: Deploying camApp from Qt Creator
« on: May 16, 2018, 08:27:06 AM »
Dear David and the rest of Krontech,

I am sorry to keep bothering you about the SW. I am very close to my goal of making an internal trigger that stops the recording if a sudden burst of light appears. I just need a few more suggestions and maybe you can help. (Right now my trigger algorithm slows down the camApp, so it only processes something like 50 fps)

It is my understanding that the camApp runs three parallel threads. Is it possible to shut down one or two of them in order to save processing time? And how would this be done?

Is it possible to turn of the display? Either by using a specific function or by removing all the functions that make the image for the display?

Do you have other suggestions that would save me processing time? 

Maja

13
Software Dev / Re: Deploying camApp from Qt Creator
« on: May 07, 2018, 12:19:41 AM »
Dear David,

Thank you very much, it helped a lot! We now have a functioning internal trigger :D
Don't worry about the diagram. It would still be very useful, but we can manage without.

Ideally I would like to turn of the screen, video and everything. Is there an easy way to do that?

Maja

14
It worked. Thank you! Do you know what causes it or how we can avoid the issue?

15
Thank you very much! I'll try that.

Pages: [1] 2