cannot find -lloguru

[alphafox02]

Right up front, I'm not using the Raspberry Pi image mentioned in the instructions. I assume that's the issue preventing me from building this project successfully when running make gps_sim_gui_arm. Instead I'm using the Ubuntu 20.04 aarch64 image.

Would it be possible to build the loguru against that build? I've also tried building on an x86_64 platform with make gps_sim_gui and I'm also unable to build. I'm attempting to pull down loguru and see if there's anything I could do myself, but I've never used it before.

I'm assuming you have already done something on your end since the /lib/loguru/bin is already populated with files.

[BeyondPerception]

Could you post the log from the build failure?

You don't really need to be using the Raspberry Pi image linked in the README, but I'm surprised it's not building on an x86 system.

Here are the steps to compile the loguru library for this project on your aarch64 system:

$ git clone https://github.com/emilk/loguru
$ cd loguru
$ g++ -c loguru.cpp -std=c++11 -lpthread -ldl
$ ar rvs libloguru.a loguru.o

Then move the libloguru.a file into lib/loguru/bin/arm.

I'm honestly surprised anyone is using this project, but let me know if you need any help getting it running. It's still WIP at the moment, but it's in a usable state.

[alphafox02]

Thank you for the quick response. Built perfectly fine following your steps above on the aarch64 Pi build. The GUI pulls up fine. I’ll try the same on the x64 setup and eventually try out the hackrf.

[BeyondPerception]

Awesome. On x64, make sure you are compiling with either just make or make gps_sim_gui, or it will try to use arm version of the loguru library.

[alphafox02]

I didn’t want to open a separate issue till I can test more, but thought some immediate feedback may be of use. With a hackrf and libhackrf 2021 to match the firmware I built from this projects git page - I’ve only once been able to get the red transmit light to come on for about 2 seconds. I’m not sure if the hackrf is intended to be running off the pi, but that’s how I have it setup while I call the GUI directly from the desktop to test. Everything appears to be working, when generate is clicked the GUI sees the hackrf and I get one quick flash on the green light before it attempts to transmit, GUI says it’s transmitting but the red light is off. Resetting doesn’t help. Super cool program though, might be something I’m just doing wrong.

edit: I can see without generate running that the green light on/off corresponds to me clicking the start/stop at which point it attempts to open the hackrf and fails with hackrf not found. Although it is found with HackRF_info when ran separately.

Thanks!

[BeyondPerception]

You need to wait for the gps simulation file generation to complete before you can start transmitting (I'll add a feature to the gui so the transmit button is disabled until the generation is complete). You can tell the generation is done from the log in the bottom right.

As for the hackrf not being detected, maybe try an unplug and replug? What is the error the program is displaying when you press the transmit button?

[alphafox02]

I was definitely not waiting till it built. I was making the assumption I needed to transmit while the numbers were scrolling in the bottom right. I lowered the sim duration to its lowest setting and waited till it completed. The hackrf is loaded with the modified firmware and detected along with gps in the upper right corner box.

When I click transmit the bottom right box said hackrf_open() failed: hackrf not found (-5) Requesting stop of hackrf_transfer Stopping hackrf transfer.

I can switch to another terminal and verify I can use the hackrf. Unplugged and rebooted. I’ll keep trying, but at least now I know to wait for the generation to complete.

[BeyondPerception]

Quick note: you only need to generate the simulation file once, so you don't have to wait each time you want to transmit. There will be a short loss of lock when the simulation file loops, so generally a longer file is better, but it will also take up more space.

If you're ok with doing a little hacking, could you try changing line 105 in src/HackRfController.cpp (i.e. std::this_thread::sleep_for (2s);) to something like std::this_thread::sleep_for (10s);. That error indicates that the board may still be starting up by the time the hackrf_transfer program starts, so maybe adding a longer delay will help.

[alphafox02]

So the longer delay fixed it. Just rebuilt the GUI after making the change. Attempting to build a bigger file now because although it transmits, I’ve not seen the GPS receiver pick up the coordinates. It just gets knocked offline. I might need a bigger box to space things out further or maybe it’s the antenna, at any rate it looks to be all running now.

[BeyondPerception]

Nice. 10 seconds is probably overkill, but keep it for now. I'll add something more robust than a delay to wait for the hackrf to come back online soon.

Also let me know if you can't get the receiver to get a fix. I went through quite a bit of head banging before I got it working consistently (which required patching the hackrf firmware lol). I can send you a picture of my setup if that would help as well.

[alphafox02]

I only have a few antennas, a triband and then one of the PlutoSDR antennas laying around. I’ve not got a lock yet, cgps doesn’t seem to see anything when the hackrf is transmitting. I just realized that I did downgrade from libhackrf to the 2018 version thinking that’s what your modified firmware was built for. Should I stay on 2018 or go back to 2021 libhackrf? I did build the firmware from your git and flashed it. That’s how I’m running it now. Picture might help if you get a chance.

[BeyondPerception]

I'm not using libhackrf in this project, I just directly call the hackrf binaries, so that shouldn't matter. I use the 2018 version of the hackrf package because that is what debian distributes, so that shouldn't be a problem either. Another problem I've seen is that some gps receivers, particularly the ones in newer phones (iphone 8+, pixels, etc.), have strong anti-spoofing measures by either sanity checking with cellular data or using other techniques that are honestly a bit over my head.

You can ensure the correct firmware is loaded on the hackrf by watching the three lights right of the DFU button (1v8, RF, and USB) flash when you press transmit or type hackrf_spiflash -R. If only the usb light flashes, then you're still running the default firmware.

Here's a picture of my setup:

I don't know if the higher accuracy clock is truly necessary, but I've heard it helps in getting a lock on more finicky gps receivers.

I've also tested this setup with the Telit HE910 GPS.

I'm going to call it a night today, but I can help more tomorrow.

[alphafox02]

Thanks for the pictures. I’d better do the same, it’s late.. I think it might be the clock though, didn’t even think of that. I don’t have one installed, I did notice I think briefly a sat or two that I never usually see come up for a sec in cgps. I’ll have to pick up a clock and try it. The gps I’m using is just a usb BU 353.

[BeyondPerception]

You may also want to check that your hackrf is actually transmitting using a spectrum analyzer or an app like GPS test for android that shows individuals satellites.

[alphafox02]

I checked, it’s for sure transmitting. I went an ordered an external clock for like $15 and should have it soon for further testing. Awesome work! The GUI is really nice. Would you eventually expand it to the bladerf, usrp or lime? Would it be possible to feed it/ transmit glonass etc?

[alphafox02]

Still waiting on my clock, but wanted to let you know the same procedures above for compiling works fine on x64. Waiting for the clock to test all the new updates I see pushed, thank you again.

[alphafox02]

Gps fix almost instantly once the external hackrf clock was installed. Tested with the latest source.