Strange behavior with Amungo Nut4nt

Signal processing; Software GNSS Receivers; bugtracker and your suggestions
Micaela
Posts: 6
Joined: Mon Jul 24, 2017 10:36 am

Strange behavior with Amungo Nut4nt

Postby Micaela » Mon Jul 24, 2017 12:49 pm

Dear all,

I am using the Nut4nt - board with nt1065‎. In particular, I have modified the AmungoFx3Dumper so that it only configures (flashes firmware with .img file and inits the device with a .hex file). I perform the grabbing using our own grabber tool, running under Linux using libusb. Our grabber tool has been slightly modified to work with the Nut4nt, according to the AmungoFx3Dumper source code: for example some libusb functions calls were commented, such as the one providing a START command with libusb_control_transfer, since it seems that the nt1065‎ doesn't need it (it is correct? In this case, when exactly it starts to transfer data? and stop it?).

In any case, hereafter the behavior I encountered.
At first, I flash firmware and configure the device with the following registers values (sorry, but I get and error if I try to attach the .hex file) and then I launch the grabber tool.

;NT1065
Reg0 00
Reg1 00
Reg2 03
Reg3 00
Reg4 03
Reg5 00
Reg6 1D
Reg7 00
Reg8 00
Reg9 00
Reg10 00
Reg11 19
Reg12 0F
Reg13 03
Reg14 16
Reg15 0B
Reg16 34
Reg17 F1
Reg18 EA
Reg19 0B
Reg20 03
Reg21 16
Reg22 0B
Reg23 34
Reg24 F1
Reg25 EA
Reg26 0B
Reg27 03
Reg28 16
Reg29 0B
Reg30 34
Reg31 F1
Reg32 EA
Reg33 0B
Reg34 03
Reg35 16
Reg36 0B
Reg37 34
Reg38 F1
Reg39 EA
Reg40 0B
Reg41 03
Reg42 9E
Reg43 91
Reg44 00
Reg45 00
Reg46 7B
Reg47 91
Reg48 00
Reg49 BD
Reg50 0C
Reg51 64
Reg52 A8
Reg53 5B
Reg54 E5
Reg55 57
Reg56 E4
Reg57 DD
Reg58 0C
Reg59 64
Reg60 A8
Reg61 C5
Reg62 6D
Reg63 57
Reg64 71
Reg65 7F
Reg66 00
Reg67 C9
Reg68 86
Reg69 7E
Reg70 0F
Reg71 11
Reg72 00
Reg73 00
Reg74 FF
Reg75 1A
Reg76 AD
Reg77 99
Reg78 0B
Reg79 40
Reg80 08
Reg81 30
Reg82 FF
Reg83 1A
Reg84 AD
Reg85 99
Reg86 0B
Reg87 40
Reg88 08
Reg89 30
Reg90 FF
Reg91 0A
Reg92 AD
Reg93 99
Reg94 0B
Reg95 40
Reg96 08
Reg97 30
Reg98 FF
Reg99 0A
Reg100 AD
Reg101 99
Reg102 0B
Reg103 40
Reg104 08
Reg105 30
Reg106 00
Reg107 00
Reg108 00
Reg109 00
Reg110 00
Reg111 00


I perform many data collections, without reconfiguring the device, since I assume that the device should remain configured till it is connected to the USB. The first data collection is always good: I clearly see the GPS bump at IF and I am able to successfully acquire and track signals. Problems starts from the second data collection on: for some data collection the collected data are not so good: I mean, signal is there, but no GPS bump is visible, only few satellites are acquired with poor C/N0.

For example, I performed a data collection of 10 seconds and I repeated it after a minute for several times: the above described behavior happens only for even data collections (2nd, 4th, 6th and so on). For this reason, I have inserted the patch I have found in your source code: stop and restart the grabbing for "even" data collections. It seems working. :D
But if a reduce the idle time between a data collection and the next one (to some seconds for example), again the problem appears, i.e. the patch doesn't work. :(
It seems like that the device has a transient time after the grabbing is finished to perform some clean-up or calibration operation. Is it so? In particular, that behavior makes me think it should be related to some king of AGC adjustment. Is my configuration setup correct? :roll:

Any ideas or suggestions?

Best Regards


Micaela

Micaela
Posts: 6
Joined: Mon Jul 24, 2017 10:36 am

Re: Strange behavior with Amungo Nut4nt

Postby Micaela » Tue Jul 25, 2017 9:25 am

You're welcome :D
I hope someone could help me and that of course this post could be useful to the Amungo community. :)

User avatar
itsar
Posts: 12
Joined: Tue Sep 06, 2016 5:01 am

Re: Strange behavior with Amungo Nut4nt

Postby itsar » Wed Aug 02, 2017 2:54 am

Hello Micaela!

I'm sorry for the late answer. We had a bug with even starts and it was fixed about two months ago.
Please update the software and firmware and try again. If this bug appears again let us know please.

Igor Tsarik
Amungo Navigation

amungo coder
Posts: 22
Joined: Tue Sep 06, 2016 5:37 am

Re: Strange behavior with Amungo Nut4nt

Postby amungo coder » Wed Aug 02, 2017 3:28 am

Micaela wrote:some libusb functions calls were commented, such as the one providing a START command with libusb_control_transfer, since it seems that the nt1065‎ doesn't need it (it is correct? In this case, when exactly it starts to transfer data? and stop it?).


You should leave START command. It can be useable in later fx3's firmwares.

Micaela wrote:Problems starts from the second data collection on: for some data collection the collected data are not so good: I mean, signal is there, but no GPS bump is visible, only few satellites are acquired with poor C/N0.


It was shamefull bug in fx3's firmware. LNA's power were disabled on every even run. We've fixed it in fx3's firmware. Use version 17050700 or later.
P.S. 17050700 means 2017.may.07, build-00
Best regards,

Viktor
Amungo Navigation

Micaela
Posts: 6
Joined: Mon Jul 24, 2017 10:36 am

Re: Strange behavior with Amungo Nut4nt

Postby Micaela » Wed Aug 02, 2017 4:12 am

Dear Igor and Viktor,

thank you very much for your precious feedbacks and instructions :D :D
I was quite sure to have used the last version of firmware and software, downloaded from Github (https://github.com/amungo/AmungoFx3Dump ... /hw_images), but it is version 17021400, not the 17050700 that Viktor mentioned. :roll:
Now I see that the 17050700 version can be downloaded from here (https://drive.google.com/drive/folders/ ... nJhUXJPR1E) :D Sorry, but I have always referred only to GitHub link, and never to Drive link, just supposing that the two links were aligned.

I will proceed to download and use the last version of the firmware (https://drive.google.com/drive/folders/ ... nJhUXJPR1E) and I will leave the START command in my grabber source code.
But where exactly can I find the last version of the AmungoFx3Dumper source code? I can only find it here (https://github.com/amungo/AmungoFx3Dumper), where in the main.cpp file (https://github.com/amungo/AmungoFx3Dump ... c/main.cpp) there is still this patch:

................................
dev->startRead(nullptr);

// This is temporary workaround for strange bug of 'odd launch'
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->stopRead();
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->startRead(nullptr);
................................

I guess now it is not necessary any more, since it has been solved in the firmware. Is it right?

Best Regards


Micaela

amungo coder
Posts: 22
Joined: Tue Sep 06, 2016 5:37 am

Re: Strange behavior with Amungo Nut4nt

Postby amungo coder » Sat Aug 05, 2017 7:19 am

Micaela wrote:Dear Igor and Viktor,

But where exactly can I find the last version of the AmungoFx3Dumper source code? I can only find it here (https://github.com/amungo/AmungoFx3Dumper), where in the main.cpp file (https://github.com/amungo/AmungoFx3Dump ... c/main.cpp) there is still this patch:

................................
dev->startRead(nullptr);

// This is temporary workaround for strange bug of 'odd launch'
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->stopRead();
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->startRead(nullptr);
................................

I guess now it is not necessary any more, since it has been solved in the firmware. Is it right?


Hello, Micaela!

Your are right it's not necessary. But this code also does not interfere. So you can use it with last firmware.

Sorry for the mess with the sources and firmwares.
Best regards,

Viktor
Amungo Navigation

Micaela
Posts: 6
Joined: Mon Jul 24, 2017 10:36 am

Re: Strange behavior with Amungo Nut4nt

Postby Micaela » Mon Aug 07, 2017 3:30 am

Dear Viktor,

thank you again for the clarification :)
As said, I will try with the latest firmware and let you now ;)

Best Regards

Micaela

Racraft
Posts: 1
Joined: Sat Aug 05, 2017 9:19 am

Re: Strange behavior with Amungo Nut4nt

Postby Racraft » Sat Aug 12, 2017 4:59 am

Micaela wrote:Dear Viktor,

thank you again for the clarification :)
As said, I will try with the latest firmware and let you now ;)

Best Regards

Micaela


Did it work for you Micaela?

Micaela
Posts: 6
Joined: Mon Jul 24, 2017 10:36 am

Re: Strange behavior with Amungo Nut4nt

Postby Micaela » Thu Sep 07, 2017 5:46 am

Racraft wrote:
Micaela wrote:Dear Viktor,

thank you again for the clarification :)
As said, I will try with the latest firmware and let you now ;)

Best Regards

Micaela


Did it work for you Micaela?


Hello,

thank you for the question and sorry for the late answer!
I have tried with the new firmware and it successfully works! :D
In particular, I have removed this patch:
................................
dev->startRead(nullptr);

// This is temporary workaround for strange bug of 'odd launch'
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->stopRead();
std::this_thread::sleep_for(chrono::milliseconds(100));
dev->startRead(nullptr);
................................
and it works! :)

Just a minor thing: it doesn't accept the START command. To be really precise it doesn't accept the following commands:
......................................
libusb_set_configuration
libusb_set_interface_alt_setting
libusb_control_transfer with start transfer command (0x01)
......................................
I have not investigated the problem, since at the end it is not a problem. I have already commented these function calls with the previous version of the firmware. Now, with the new version of the firmware I have tried to use them just for curiosity and because Viktor wrote I could leave the START command with this new firmware.
Anyway, as said, this is not an issue and I would not worry about that. ;)

Thank you for your kind support!

Best Regards

Micaela


Return to “Signal processing and Software”

Who is online

Users browsing this forum: No registered users and 1 guest