Positioning Error on Autotalks EVK

[lo-hei]

Hi,

I work with a Craton2 EVK from Autotalks. Vanetza is compiled (with DSOCKTAP_WITH_GPSD=ON). For this, GPSD was cross-compiled on the local machine and added to vanetza-deps folder. the files libgps.so, libgps.so.30 and libgps.so.30.0.0 are copied onto the EVK to /vanetza/lib.

But if i try to run ./socktap -l autotalks i just get following:

root@autotalks:/usr/bin# ./socktap -l autotalks
Starting runtime at 2018-Mar-09 12:46:54.959933
Platform without TEE support
Using default value v2x_service_broadcast_disable=0
Using default value ivn_service_broadcast_disable=0
Using default value log_level_host=3
GNSS device source config: internal poti disable = 0 internal baud rate = 0 internal 1Hz cycle ender = 0 internal poti type = 1 internal poti message format 1
           external baud rate = 0 external device=1 external port = 0 external 1Hz cycle ender = 0 external poti type = 1 external poti message format 1
GNSS device source config: offset seconds = 0
Initiating POTI device /dev/ttyAMA1, baud rate 230400, cycle enders ($PSTMCPU, $XXGLL)
Device on M3
Shared memory ll_init done, memory size is 16384[bytes]
ll_interface_init done - app_role 2
Device and services are registered and initialized
Using default value lmac_calib_file_location=1
Using default value lmac_rf_config_file_location=1
Using default value force_csk_generate=0
Using default value log_level_device=3
Using default value lmac_loopback_enable=0
Using default value lmac_phy_loopback_enable=0
Using default value lmac_trace_verbose=0
Using default value swc_version=1
Using default value lmac_ranging_enable=0
Using default value lmac_dcc_indication_enable=1
Using default value physical_interfaces_in_use=0
Using default value lmac_diversity_enable=0
pthread_create success!
Receive failed: 2, Invalid argument, RX thread ends.
Exit because of positioning error: unknown error

If I had to guess, it could be due to two problems (or both):

• now there is no installed GPSD on the EVK, just the copied libraries in vanetza/lib. I would think that the gpsd deamon has to run? In that case i am not sure which folders and files i have to copy onto the EVK. After cross-compiling i received a gpsd-VERSION folder on my local machine with multiple other folders (e.g. gps, gpsd, include, libgps) an files (so-files).
• maybe my initialization code is wrong. For that i just copied the ~28 lines Reference system initialization Code and needed varaibles from the v2x-example into the autotalks.cpp

Thanks for the help. I really appreciate your efforts @Irisbus

[khevessy]

Sorry, I haven't used GPSD on Craton, but is it really necessary? I have created AutotalksGps module, that created a thread that was fetching the GPS data using the Autotalks API (inspired by the poti-api-example from the SDK) - basically just periodically call poti_fix_get() on poti_context_t structure.

[lo-hei]

Maybe then it is not necessary. All I need is a running socktap application that periodically sends CAM messages with the current GPS location. The lack of the GPSD library was just an attempt to explain the error, since I don't know what else it would be.

[khevessy]

No, it is not necessary. You can build socktap without support for GPSD. Does the example run when you try to use static position? I do not know what exact changes you did to the example, but in the default state, if you are running the example as ./socktap -l autotalks, you do not even start the GPSD location provider but use the "static" one that is defined in positioning.cpp.

Edit: Are you sure that you are showing the full command (./socktap -l autotalks) you are running? It seems to me that the exception Exit because of positioning error: unknown error is being thrown by GpsPositionProvider constructor that is used when you provide -p gpsd or something similar.

[lo-hei]

Yes, it is running with -p static and i can send and receive CAM-Messages (already tested with two EVKs). I left -p gpsd out because after compiling with DSOCKTAP_WITH_GPSD=ON this is the default. Is this not correct? What is the correct --position argument? Or what should be the correct command for using the internal GPS? I saw there are additional attributs like gpsd-host and gpsd-port. Edit: At this point, I have not made any changes to the program. Only added the initiazization as requested in your instructions.

[khevessy]

I left -p gpsd out because after compiling with DSOCKTAP_WITH_GPSD=ON this is the default.

Oh okay, I did not notice that, sorry.

I think you should not use GPSD at all. As I said before, in our real application, I created a new module, that fetches position from the Autotalks API (this is for now not part of the socktap example).

Generally how did I did it:

• Create a new class AutotalksGps that inherits from vanetza::PositionProvider. Main methods to implement:
  • Constructor (with initialization similar to Autotalks SDK example)
  • AutotalksGps::scheduleTimer() that schedules timer
  • AutotalksGps::cancel() to cancel timer and deinit the whole GPS,
  • AutotalksGps::onTimer() timer callback that periodically calls method AutotalksGps::fetchPositionFix(),
  • getter position_fix() that reads the fix updated by AutotalksGps::fetchPositionFix()
  • AutotalksGps::fetchPositionFix() for fetching the GPS data using the Autotalks API (inspired by the poti-api-example from the SDK)
• Override the create_position_provider() function with constructor of AutotalksGps using new

Hope it is somehow clear. Do not know how "correct" this is but I did it like that. Sorry, I did not put it here to the pull request as I thought that it is trivial to implement using the Autotalks SDK. Maybe I should add a note somewhere that for socktap with Craton link layer, there is only a static position fix implemented in this repository. Or you can make the example yourself, but I fear there is too much Autotalks code to put here anything constructive.

If you need any more guidance, you can ask here, but I think the main thing is that for now, you have to implement this yourself.

P.S. In the future, if I get to it, I may add the code to the pull request. But do not count on it for at least the next few weeks.