Mayhem 1.5.3 vs 1.5.4 (and later)

[voxo22]

hey guys, is there any difference in the base hackrf FW module between Mayhem versions 1.5.3 and 1.5.4? It's weird. I'm using the ODR-mmbTools software for DAB+ broadcasting in conjunction with HackRF on Linux. I have found that from FW version 1.5.4 (up to 1.7.4) the broadcast signal is accompanied by nonstop but random short dropouts (around 50 to 100 ms), to which the DAB receiver responds "out of SYNC". The received programme is therefore constantly interrupted and cannot be listened to at all. As soon as I loaded version 1.5.3, everything goes smoothly without any dropouts. Tested on two different HackRF boards (2014 and 2020), H1. I am going crazy about this. Can you explain, please?

[NotherNgineer]

To determine exactly which change caused this behavior, I would recommend testing nightly releases between 1.5.3 and 1.5.4 to determine the exact date when the problem was introduced. (Personally I don't have any idea about those old FW versions [they won't work on my newer PortaPack], so Just a suggestion.)

[jLynx]

@voxo22 you me a you tested 1.5.3 on one board and 1.5.4 on another, or do you mean you tested both versions on both boards?

[voxo22]

@jLynx yes, tested on both boards, both FW versions. I found the location of problem (from this revision it keeps failing): Revision (n_220605): @jLynx: Fix for new H2+ devices (https://github.com/eried/portapack-mayhem/pull/666)

[jLynx]

So just so I understand completely. You are using it in Hackrf mode connected to your computer, correct?

[voxo22]

sure.... hackrf mode

[jLynx]

Hmm that's odd, this change does not touch hackrf mode. So it still doesn't work on the latest nightly?

[voxo22]

are you sure? there is submodule update... you mean should I have to test the latest nightly, even if 1.7.4 or any other version down to 1.5.3 fail? (i have tested 1,7.4, 1.7.3, 1.7.1, 1.7.0, 1.6.0, 1.5.4)

[jLynx]

Sorry missed the part where you said you tested 1.7.4. So that should be fine. And sorry again, you are completely right, there was a submodule update. In that case, there probably needs to be an issue opened on this repo https://github.com/greatscottgadgets/hackrf as that contains the code causing your issue.

[jLynx]

We are currently on this version https://github.com/greatscottgadgets/hackrf/tree/50c22aa05b5fc8a788faf9b4a58b4c134b777d1c.

There has been updates so if you could just try flash the latest normal hackrf firmware on master from that repo and see if that fixes your issue. If it does we can then update it on the mayhem repo

[voxo22]

hmm. can you please give me any hint, how to install it correctly? I am on windows now.

[jLynx]

I'm out at the moment, maybe one of the other devs could compile it and upload it here for you. @gullradriel maybe?

[Brumi-2021]

Hi , I think there are just two commits more after our current Hackrf submodule update from 8th of May (50c22aa05b5fc8a788faf9b4a58b4c134b777d1c) , but they do not seem related to the code.

[Brumi-2021]

Hello @voxo22 ,trying to help you , I tried to compile current mayhem with several different old versions of the submodule Hackrf for you . But I only got good compilations using this year HackRF versions . But I got too much errors when trying to go to HackRF dec 22 versions . Therefore I am afraid I can not help you .

I think , you should better disassemble Portapack from HackRF , and flash your HackRF board with different HackRF versions , and find out if current HackRF version (alone, without mayhem ) shows you the same problem . And if does , go back to older hackrf fw versions to see if the older version used in our 1.5.3 was ok . If so , you should better open a new issue in the HackRF GitHub project .

[voxo22]

Hello @Brumi-2021 , thank very much for your help. I am afraid, that I am unable to find usable release of "hackrf" version only, which I can simply flash. Do you have a clue, how to do that really simple? I mean there are only DFU ways possible, or any other way? Can we wait with closing this issue until I do this test?

[Brumi-2021]

Hello , not only DFU way . But DFU is a powerfull tool to always recover our device from any sw bricked situation. So do not be afraid about DFU , it should be your “friend”.

Anyway even having now both boards together (portpack + hackrf together ) you can put the Mayhem in Hackrf mode , then having active USB communication, reflash only Hackrf one fw . But from that point , you will need to switch off , disassembly both boards and work with Hackrf board alone . And in that situation, I think by default Hackrf one board has always activated the USB communication , that means that you can test that version , and at any time reflash it again with another older Hackrf one version (without DFU, as long it is not fw bricked) .

We will not close that issue , till you confirm us that this problem that you pointed in mayhem been in HackRF mode is fully related to a specific Hackrf fw version and onwards .

[voxo22]

I tested 3 releases of HackRF FW submodule (without portapack): 2023.03.1, 2022.09.1 and 2021.03.1. Only 2021.03.1 worked correctly with ODR tools. This means the bug is in the submodule. I can't test other versions (commits), I don't have enough knowledge how to compile it. Do you suggest then to file the issue to greatscottgadgets/hackrf?

[Brumi-2021]

Hello @voxo22 , thanks for your testing and sharing your report . Guauuu if only 2021.03.01 is working well to you , it is too much distance , more than two years … I guess maybe hundreds commits between .

But I think our mayhem 1.5.3 (may 2022) did not use such too old HackRF submodule March-21 version, not ?

Anyway , Yes , as you suggested , I think you should better open that issue in their GitHub HackRF GSG project , explaining very well , talking about the set up , tools , and how to reproduce that problem using HackRF alone (or in HackRF mode in Portapack ).

And if you want , pls later , add here the link to that HackRF project issue , for our progress tracking.

Cheers

[voxo22]

it's exactly 1 year, because it was working until 2022.09.1 update. Ok, I am going to raise an issue there.

[Brumi-2021]

Hi @voxo22 , thanks I saw your post and very quick answers from HackRF team , https://github.com/greatscottgadgets/hackrf/issues/1359

[voxo22]

Yeah! as mentioned and discussed on the other post above, later I discovered that I had misconfigured the USB port, for some reason only protocol 1.1 was being used and not 2.0. After the correction everything works as it should. So for me perfect, everything works like a charm now!