pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
337 stars 209 forks source link

PiHPSDR not running with latest build #491

Closed ka6s closed 7 years ago

ka6s commented 7 years ago

Pavel,

I am having issues running PiHPSDR with the current HPSDR version. I created my own bit file - no issues with the compile, and compiled the server - again no issues. When I start up PiHPSDR - it does the Metis hand-shake finding the server, then the GUI starts up - but it looks like it isn't getting any IQ data, i.e. the Panadapter is blank. I've had tried the bit file and server combination with PowerSDR - and that works - so likely the issue is PiHPSDR - but I'm at a loss as to where to look first.

So I guess I have a couple questions that are still escaping me after staring at both sides of this for a few hours. 1) Can you point me to where the actual I/Q data is sent in the server code (line numbers work..) and 2) What causes the IQ data to start flowing (and where in the server code?)

Obviously I have the source to both sides of this and need some help in figuring out where it's getting lost on the PiHPSDR side.

Thanks!

Steve KA6S

laurencebarker commented 7 years ago

Interestingly I have had the same. I didn't know it was because it was a new version. I used wireshark and tracked down what was happening differently between pihpsdr and PowerSDR.

pihpsdr sends 10 ethernet packets of data before sending a "start" frame. There is code in old_protocol to send 10 USB frames in a loop, then it's repeated to do the same again. Round about 150 lines from the end as I recall. If you comment out the second look (so it only sends 10 USB packets/5 ethernet packets, it works.

I suspect a FIFO is overflowing - have any of the red pitays FIFOs been reduced in size?

Laurence Barker G8NJJ

ka6s commented 7 years ago

Laurence,

Can you be more specific - are you talking about 150 lines from the sdr_transceiver_hpsdr.c in Pavel's code or in PiHPSDR old_protocol.c? Help here is MUCH appreciated!

Steve

laurencebarker commented 7 years ago

It’s in pihpsdr old_protocol. I’ll be able to send more details tomorrow.

Laurence Barker

laurence@nicklebyhouse.co.uk

ka6s commented 7 years ago

Laurence, Pavel -

I found what Laurence is referring too:

In PiHPSDR - old_protocol.c

The routine:

1076 static void metis_restart() { 1077 // send commands twice 1078 command=0; 1079 do { 1080 ozy_send_buffer(); 1081 } while (command!=0); 1082 1083 do { 1084 ozy_send_buffer(); 1085 } while (command!=0); 1086 1087 // start the data flowing 1088 metis_start_stop(1); 1089 }

Should be changed to: 1076 static void metis_restart() { 1077 // send commands twice 1078 command=0; 1079 do { 1080 ozy_send_buffer(); 1081 } while (command!=0); 1082 1083 // do { 1084 // ozy_send_buffer(); 1085 // } while (command!=0); 1086 1087 // start the data flowing 1088 metis_start_stop(1); 1089 }

And this seems to work - not sure WHY though?? Pavel - any suggestions here??

Steve

laurencebarker commented 7 years ago

Hi Steve

I found that around a week ago. I didn't know there was a new build - I just assumed it was some configuration I hadn't got right yet. The Red Pitaya worked fine with PowerSDR, and the number of data packets sent before the "start" packet was the only significant difference. The standard doesn't specify a number, so both PowerSDR, pihpsdr and Pavel's code are all compliant. I decided to find out why later.

I'm trying to get to the point where I can rebuild and re-install the Red Pitaya code, so I can interface my Arduino and RF front end as another I2C device. Then I'll start to worry about all the little issues I've swept under the carpet in the meantime. Like not being able to build the bootable memory card....

Pavel - nice code and nice description of how to use the Red Pitaya - thank you.

Laurence Barker G8NJJ

pavel-demin commented 7 years ago

Looks like I'm late to this issue but I'll still try to answer some questions.

1) Can you point me to where the actual I/Q data is sent in the server code (line numbers work..)

The I/Q data is sent by the sendmmsg function on line 1083: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c#L1083

2) What causes the IQ data to start flowing (and where in the server code?)

The thread that sends the I/Q data is started on line 664:

https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c#L664

pihpsdr sends 10 Ethernet packets of data before sending a "start" frame. If you comment out the second look (so it only sends 10 USB packets/5 ethernet packets, it works. I suspect a FIFO is overflowing - have any of the red pitays FIFOs been reduced in size?

If PiHPSDR starts sending the TX packets before starting the RX thread, then the TX buffer could indeed overflow. I'm not sure but I'd say that the following code should be added just before the line 499 in sdr-transceiver-hpsdr.c to solve this problem:

  /* reset tx lo */
  *lo_rst &= ~16;
  *lo_rst |= 16;

This code will reset the TX LO when the server starts. This way, the TX buffer won't overflow.

ka6s commented 7 years ago

Pavel - as always - thanks for your support.

I'll give this a try in the next 24 hours or so - busy day today and might not get to it until my tomorrow morning.

THANKS!

Steve

ka6s commented 7 years ago

Pavel - this didn't make any difference in the behavior.

Steve

laurencebarker commented 7 years ago

It’s worth noting that if the problem does occur, the pihpsdr program can’t “discover” again until the RP server program has been restarted. So I think that whatever the issue is, it causes the program to exit.

Given that observation we could try to track the problem down by sending 10 ethernet frames then exiting and doing a new discover; if that works, the problem happens on or after the “start” message being sent. “start” triggers a lot of activity, so that would be interesting to try.

I’ll see if I can try that at the weekend.

Laurence Barker G8NJJ

laurence@nicklebyhouse.co.uk

laurencebarker commented 7 years ago

I thought I'd have a look at this issue this evening, and I think all I'm contributing is more confusion:

Running pihpsdr in a virtual machine on an x86 laptop tonight: the "standard" pihpsdr code (10 ethernet frames before "start") runs correctly ie the data transfers are working OK.

If I run the same code on a native linux x86 laptop: pihpsdr never gets any data (ie you don't get a spectrum on the screen). Exit and re-run the program, and it now can't discover any devices. When I ssh into the RedPitaya, sdr-transceiver-hpsdr is still listed as a process ie the c server program has not exited. It suggests that it is no longer processing ethernet packets - is it stuck in a loop or something?

Why there is a difference in behaviour between pihpsdr on a laptop and in a VM I have no idea.. I assume timing?

It'd be interesting to see if putting a small delay between each ethernet frame would make a difference - I'll have to remind myself how to do that.

karlskontorp commented 7 years ago

I have some information that might help solving the problem with blank spectrum and waterfall. First I installed the version 1.1.3 of pihpsdr - getting the blank spectrum/waterfall. I was in contact with Laurence, and he kindly sent me the version 1.0.0 of the pihpsdr, and with this version, I got spectrum and waterfall. While testing with a friend, I started the version 1.1.3 (without stopping the version already running), and of course, I got two "connections" available, one of them was marked "In use" when I searched. I clicked on the one available and the version 1.1.3 worked like a dream! In the 1.0.0 version, the spectrum and the waterfall were frozen, and I closed the program. I tested many times, and the 1.1.3 version was running with success every time. When I rebooted the Raspberry Pi, I had to run the 1.0.0 version once before I successfully could run the 1.1.3 version! It's enough to just start the 1.0.0 version and close it when you see the spectrum/waterfall is running. As long as the Raspberry Pi has got power, the pihpsdr ver 1.1.3 could be started without any problems.

I hope this can be to some help to solve the "black screen"-problem in the version 1.1.3 of pihpsdr!

Best regards Karl Jan - LA3FY

PS. The combination of the Red Pitaya with HDSDR and the Raspberry Pi with pihpsdr as a SDR is really great, thank you very much making it available to us!

pavel-demin commented 7 years ago

I've finally built PiHPSDR and reproduced the problem.

I tried the solution that I proposed in my previous comment and it worked. Here is the corresponding commit: https://github.com/pavel-demin/red-pitaya-notes/commit/55330b513dfc2b755a991b6f1bc9bc4a40da147d

I've updated the customized SD card image zip file. The link is the same as before: https://www.dropbox.com/sh/5fy49wae6xwxa8a/AAD3bGp3ptaQ-VE-adG1SijKa/sdr/ecosystem-0.95-1-6deb253-sdr-transceiver-hpsdr.zip?dl=1

Since the Red Pitaya application market place is currently broken and I can't upload my application, I've copied it to dropbox: https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABy6xZbmuxn0O6gI9EjrH-Oa/sdr/sdr_transceiver_hpsdr-0.94-1653.zip?dl=1

With this new version, PiHPSDR starts without problem.

laurencebarker commented 7 years ago

Hi Pavel

I've just returned from a week long holiday.

I've downloaded the new customised SD card image, and this version works with the original pihpsdr code on my raspberry PI. I think you could regard this as "fixed" - thank you.

Before I went on holiday, I had made some changes to sdr-transceiver-hpsdr.c to interface it to my radio hardware, which uses an "intermediate" Arduino. (The reason is: my radio hardware doesn't comply fully with the "Alex" spec, for example having bandpass rather than highpass filters). I've created a new I2C address in your code, and the Arduino picks up 6 I2C "registers" at that address. It tests for that I2C device being present,in the same way that you test for the other I2C devices; so my code changes should be OK with other users that don't have the Arduino. (I've described what I'm doing, and the I2C register interface, on my website: http://www.g8njj.org.uk/index.php/software-defined-radio/2447-a-start-in-sdr-part-9-arduino-interface

I've never been able to understand configuration management tools like git, and I don't know how to merge my changes with the latest version of your code, so that I get the benefit of future changes that you make. Would it be possible to incorporate my code into the "master" version of the program please - I will be happy to do the work but I'm not sure which is the best "stable" starting point.

(The Arduino code and the hardware details will eventually be in the public domain when I've worked out how to do that.)

Laurence Barker G8NJJ

pavel-demin commented 7 years ago

Hi Laurence,

Thanks for testing the new version. Since the problem is solved, I'm closing this issue.

I've never been able to understand configuration management tools like git, and I don't know how to merge my changes with the latest version of your code, so that I get the benefit of future changes that you make.

With GitHub it's as easy as editing the file in the on-line editor. Here is a direct link:

https://github.com/pavel-demin/red-pitaya-notes/edit/develop/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c

Otherwise, just modify the file from the master branch and send it to me by e-mail.

Best regards,

Pavel

laurencebarker commented 7 years ago

Hi Pavel

I’ve sent a modified file to your @outlook.com email address – thank you

Laurence Barker G8NJJ