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.

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. 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?

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

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! 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_configurationlibusb_set_interface_alt_settinglibusb_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.