Installation Package doesnt install

[EmeEleonu]

PikaTimer version 1.5 just runs in the background without installing.

[segfaultcoredump]

I'm assuming you are talking about the installer and that you are talking about the 64 bit windows installer.

Make sure of the following:

1) That there is not another window hidden somewhere prompting you to permit the installer to run. The installer is unsigned, so windows should alert you to this fact. 2) That you are running a 64 bit version of Windows 10 3) That your AV system did not step in and pause it, awaiting you to give it the okay.

[EmeEleonu]

Yes I am talking about 64 bit windows installer. I wasn't able to install straight, nut when I stopped the process with Task Manager and restarted the computer. I found out that it had installed. I tried to create a new race and encountered yet another problem - so I restarted again and found out that it had created the 1st race too. I am inclined to think it has to do with memory... but I have had no issues running or installing other programs before.

I am running 4.00 GB RAM, Intel Core i3-6006 2.00 GHz processor.

[segfaultcoredump]

It sounds like you worked through the installation prompts after launching the installer. After installation, the installer will auto-launch the app for you.

PikaTimer is just a basic JavaFX Stand-Alone application. Behind the scenes, pikatimer.exe is just a small shell that starts the 1.8 java jre with the following java flags: -d64 -Xmx4096m -Xms512m

It should run on a system with only 4 gigs of ram (which should be a bare minimum on a 64bit os) as long as you have at least 512M free when it starts.

When I start it on my laptop, it consumes 115G of ram. After loading in a decent sized race (800 runners with 70,000 chip reads), it will grow to 1G of ram consumed.

If it is is memory (some "4g" systems use a good chunk for the video ram), you can try this: In the PikaTimer install directory (it should be c:\users\\appData\Local\PikaTimer, there is an "app" folder. Under that is a PikaTimer.cfg file. Use notepad to edit the file. Find the line that reads -Xmx4096m and change it to -Xmx1024m Change the line that reads -Xms512 to -Xms128

And then start PikaTimer to see if it behaves on your system.

The other thing that I've seen cause problems in the past is the Anti-Virus. Most will work just fine. I've seen some go into paranoid mode where if they have not seen an app before, they quarantine it unless it is whitelisted.

A final test would be to install the 1.8_171 JRE on your system. Then open a command prompt and cd to the 'app' folder under the PikaTimer installation directory. Then run the following: java -jar Pikatimer.jar

If you use the jar launcher method I just described, you will also see a ton of debug output, which may be handy for further troubleshooting.

[EmeEleonu]

Okay did that and it seems to run much more quickly now... Thanks.

What hardware do L need to buy to test this? Readers and transponders? What make and model?

[segfaultcoredump]

I suspect that the default memory tuning may be running the unit into swap. It would make the app so slow it may not even be worth looking at.

I'll add a x32 version in the 1.5.1 release I'm working on (minor bug update for the latest Joey firmware). I always tune the memory parameters way down for those systems. I'll also add a note to the x64 version that a mid-range system is best. While a $2k laptop is not a problem for most timers who drive around with $100k worth of timing gear (I have a CF-31 Toughbook and an XPS 15 9550), but it can be an issue for the smaller timers who have a single unit and an i3 based laptop.

PikaTimer was written to interface with the Ultra and Joey timing boxes made by RFIDTiming (https://rfidtiming.com/). The RFIDTiming units are one of the first on the market to not require the use of company provided chips. The code is provided for folks to add the ability to interface with other units on the market. I only have experience with the Ultra's and Joeys, but the hope in releasing the code was that somebody else could contribute the class files for additional readers on the market.

[MistaWizard]

I will freely admit that I'm a cobbler and not a programmer but I am going to work on adding a class library for Alien readers and once I'm able to start building my business I will also look at LLRP compatible readers as well. I might be able to accomplish that quickly or it could be like some of my other projects and take a while.

[segfaultcoredump]

One thing to keep in mind when going directly to a reader such as Impinj or ThingMagic is that if you ever get disconnected during an event, those reads are effectively lost. This is a very, very bad thing. Another item is that you typically do not want just the first read, you want the strongest read during a given time period (the gating factor). Most readers will start to pickup a chip that is still 20-25ft away from the antenna.

With a unit from RFIDTiming, Chronotrack, etc, they put a small single board computer with persistent memory between you and the actual reader. This unit acts as a buffer to the actual reader(s) and allow you to store the chip reads and then pull them down later. They also let you set the gating period, sync the clock to a gps time source, and have a few other things that optimize the reader for race timing.

[MistaWizard]

That is true. I will try to stick to my initial idea and have it written out into a file in the format compatible with an Outreach or RFIDServer file. It isn't perfect but I've also put together a python script (that I'm currently testing on Ubuntu) that outputs a file that can be read by the Race Timer input class. I've got some polishing to do on it but it works with PikaTimer so far.

[segfaultcoredump]

Take a look at the user who reported Issue #18 to see if the two of you have some overlap in your goals for additional reader units.

[EmeEleonu]

Here is another Cobler - haven't coded in decades, all rusty with redundant codes... For me I am shopping for a good timing system for my Karting club, something that wont break the bank. I like the appeal of an opensource system that I can gradually localize over time - leader boards and intuitive notifications of meetings and results. Do you think this would work well for racers moving at such speeds?

[segfaultcoredump]

Motorsports can be tricky. Passive RFID systems are used for many high speed timing events. That said, I would not trust them for a photo finish.

For the cases where the 100ths or even 1000ths of a second count, you need to switch to something designed for that task. See http://www.finishlynx.com/packages/motorsports-high-speed-timing-systems/ for such a system.

[MistaWizard]

http://www.easyracelaptimer.com/

Designed for drone racing but is also open source. May be better suited for adaptation for karting.

[EmeEleonu]

Thanks Guys! www.Finishlynx.com definitely high-end designed for speeds up to 600mph, shift Karts wont exceed 60mph. I have requested for a quote all the same. cant wait to hear what the will send $$$$$. I also looked the www.easyracelaptimer.com one. sure looks like something that can be customized, but IR and line of sight may not be very reliable. Last thing you want is a failed read. But I will research both of them.