P2 has made some tremendous strides in the last 3 or 4 weeks. A number of major logic flaws have been found, and some minor ones, and with those squashed, the issue of achieving timing closure with the free version of Quartus seems to no longer be an issue.

The major reason that there has not been a public release of a beta version of P2 yet is because there are still at least two major bugs yet to be squashed, and without these being fixed things will just be an exercise in frustration for anyone who wants to try it.

The primary bug is associated with occasional un-commanded wideband packets escaping from the hardware and these cause Thetis to crash. There is another bug (at least one) that is associated with the synchronizing DDCs for diversity, PureSignal, and the like.

Be patient, standby, and soon you will see a release, I'm sure.

In the meantime, Thetis has not yet been brought up to parity with PowerSDR 3.4.9, so there is that issue to be dealt with, as well.

Just checking, any news on protocol 2 update? Honestly, I am using the present version with the latest Thetis software of version 2.60 provided by w5wc without any problems to speak of. Just curious on any progressing update?

There are much newer versions of the P2 firmware ready. They work a lot better than the versions currently posted to Github. I have been lobbying hard for their release, but so far no joy.

One of the challenges with P2 is that it causes the power consumption of the FPGA on the Hermes (14 and 16 bit versions) and Angelia cards to exceed the rating of the PTC device which protects the 3V supply. Read more here

In a perfect world, we'd all migrate to Thetis and P2 on all of our radios, and PowerSDR mRX PS would be deprecated. However, because of the hardware issues, few would modify and migrate. This would cause a situation where the dev's have to either a) support and maintain both PowerSDR and Thetis or b) abandon PowerSDR and only continue Thetis development.

I suspect the above issue may have something to do with the reluctance to fully commit to P2.

Well, at the risk of saying something that will be disagreeable to some, this seems to me to be a simple problem. Simply limit the Ethernet speed to 100mbps in the firmware for Angelia and down and the fuse problem goes away. Everyone can still run Protocol 2 and Thetis and those with Orion 2 boards can enjoy all the features that 1gbps provides and the ones with Angelia and below can enjoy all that 100mbps provides. Perhaps I'm missing something but if so, I don't see it.

I agree, it would be a way forward if it was made an option and anyone who chooses can change to Thetis. . Only downside for me personally would be no stitched receivers .Was there not a previous version of firmware for the hermes that had speed limited to 100mbps?

I don't know for certain, but the MAC (media access controller), which is in the FPGA (the PHY chip is external), is probably a major contributor at GigE speeds. There would also be the faster IF sample rate processing, if enabled (up to 1.5Msamples/sec).

To have the option of running at 100BASE-T speeds there would need to be two builds of the FPGA code, one with a GigE MAC, the other with a 100BASE-T MAC. Or both Thetis, the protocol itself, and the firmware would have to be updated to allow user selection via the client. Obviously one would face the same bandwidth limits already in place on PowerSDR when running 100BASE-T. It's an interesting option, at any rate.

You don't need stitched receivers with P2 because you can run at 768 or 1536 Ksamples/sec. 768 may be possible at 100Base-T speeds with PureSignal disabled.

As for the "design flaw" comment: the Angelia and precursor hardware was designed before P2 was even a gleam in anyone's eye. It was and is just fine for the original protocol. It's not really fair to blame someone for not meeting a set of requirements they didn't even know were going to exist.

The Design flaw has nothing to do with P2. They simply didn't know how to use poly-fuses. An experienced EE would have never madethat mistake.

Barry

w-u-2-o wrote:I don't know for certain, but the MAC (media access controller), which is in the FPGA (the PHY chip is external), is probably a major contributor at GigE speeds. There would also be the faster IF sample rate processing, if enabled (up to 1.5Msamples/sec).

To have the option of running at 100BASE-T speeds there would need to be two builds of the FPGA code, one with a GigE MAC, the other with a 100BASE-T MAC. Or both Thetis, the protocol itself, and the firmware would have to be updated to allow user selection via the client. Obviously one would face the same bandwidth limits already in place on PowerSDR when running 100BASE-T. It's an interesting option, at any rate.

You don't need stitched receivers with P2 because you can run at 768 or 1536 Ksamples/sec. 768 may be possible at 100Base-T speeds with PureSignal disabled.

As for the "design flaw" comment: the Angelia and precursor hardware was designed before P2 was even a gleam in anyone's eye. It was and is just fine for the original protocol. It's not really fair to blame someone for not meeting a set of requirements they didn't even know were going to exist.

Interesting and slightly acrimonious discussion, but for one that cannot get Protocol 2 to work in any form on my 200D, I wonder if "fuse" problems are the only issue? I also can only use ver 5.0 of Protocol 1; the others break Pure Signal for me.

I know this question keeps coming up and believe me I don’t want to offend anyone by any means. Is there any news on the protocol 2 firmware update? I have read that there is a very new beta version out there but has not been officially posted/released. Would it be of any value for testing purposes to release the newest version with the understanding that it is at the user’s risk? The saying of “ no reward without risk” really bodes well with a lot of the hpsdr group or for me it is the “bleeding edge” of technology advancement. I and I know many here really appreciate the hard work put into open hpsdr, without the select people spending many hours on the sdr advancement of software and hardware, sdr in itself would have fallen by the wayside a long time ago. Anyway, thanks for all of the work and if possible please release any improvement of software.