ik1xpv commented 2 years ago

I received a request from Joanne Dow.

Two RX888s on the same system at the same time? Is there a way to change the serial number on one of them so that they can be unambiguously selected?

fventuri commented 2 years ago

Oscar, I wonder if it would be possible to expose in the USB descriptor (in a field called say 'serial number') the FX3 unique id, which is discussed in these threads in the Cypress community forum:

Franco

ik1xpv commented 2 years ago

Franco, Thanks for the advice. I'm quite confused. The Cypress library solves many of our needs and I would like to keep the booting scheme in ram that allows us to update the firmware automatically. I'm playing some rude tentative approach. When there are two ( or more :-) ) Cypress compatible devices that enumerates I ask the user witch device to open. This morning it run at least once see picture ... 2devices When I reach a consistent code I commit it on a tentative branch.

Oscar

fventuri commented 2 years ago

Oscar, while your solution of opening a new dialog box and asking the user to select between one or the other RX888 works for the interactive use of HDSDR, it might pose problems for a library approach, for instance for a SDR Console user, or for SoapySDR, or for a GNU Radio module.

In most SDRs it is customary these days to assign a unique serial number (typically arbitrarily defined by the vendor), and most client libraries allow to select among similar devices based on this unique id.

What I was thinking is using the solution proposed here: https://community.infineon.com/t5/USB-Superspeed-Peripherals/FX3-Device-Name/m-p/287956 combined with the method in my previous comment to just extract the unique id of the FX3 (or you can make up any other id, as long as it stay consistent across shutdowns and reboots - and even better if it stays the same even if the device is moved to a different USB port or connected via a USB hub) and make it visible in the 'serial number' USB field (which I think is part of the USB specification).

Not sure about your concern of "keeping the booting scheme in RAM", since I think the registers mentioned in those posts are 'E-fuse ID registers', and my understanding is that those are not in RAM, but in some read-only location in the FX3 address space.

This said, these are just suggestions; you and Howard are much more familiar with the RX888, its hardware, firmware, and the code in the driver, so I am definitely OK with the solution you choose.

Franco

ik1xpv commented 2 years ago

I agree that this could work only in the interactive use. Some random thoughts... The first time we connect to PC and switch on the FX3 in BBRF103, RX888 ... the device enumerates as Cypress Boot-loader descriptor with a fixed Serial number. https://www.cypress.com/documentation/application-notes/an76405-ez-usb-fx3-boot-options Then ExtIO_sddc loads the FX3 firmware via the USB Boot-loader to the RAM where it's executed and re-enumerated as Streamer. I imagine that is quite impossible to diversify the Serial Number of the boot code as it's proprietary. The FX3_SDDC firmware can be modified as we like but first we have to identify the device at Cypress boot. Descirptors

Ciao, Oscar

fventuri commented 2 years ago

Ciao Oscar!

I honestly don't understand why the initial serial number (the one for the raw boot loader) matters at all; at that stage the BBRF103/RX888 is just an "amorphous piece of hardware" incapable of anything but loading the firmware, and the only thing any client application/library can do with it is to load some sort of firmware.

However after the firmware is loaded and the USB re-enumeration has occurred, the SDR "becomes alive" and at that point having a unique, stable id for each SDR can be useful; for instance I envision the case of a user with multiple of these BBRF103/RX888 who has put one of those Dymo labels (that shows my age!) on each of them with say the last few digits of the serial number/id, and no matter how they move them around, different USB ports, different PCs, they always know which is which.

The interactive prompt that allows a user to select the SDR, could then show a selection list like:

SDR#1 (S/N=123456...)
SDR#2 (S/N=7890AB...) and so on.

I hope it makes sense, Franco

ms-jdow commented 2 years ago

That is a more general solution. From this discussion the email I was starting for Oscar suggests the running code is loaded into ram and the only alternative is not quite a write once solution. If the code image sticks around I had figured we could save something like eeprom from write cycles by looking at a code version number in that image. Within the image there could be a place for a moderately unique identifier.

Franco, one of my usage models would be almost always connected without connections moving around with separate antennas. With antennas on opposite corners of the property here I could almost independently compare which antenna gives better SINAD on a distant signal. Another would be one antenna for burning clouds (NVIS) and the other for reaching out and touching DX. The first model is feasible here up to 64 Msps on my machine. It probably won;t work without reducing FFT resolution for 128 Msps. This would be running SDR Console. That's with everything else running, too. EMail, a dual SDR receiver for temperature and humidity dongles, and my favorite background music KUSC (75 years old tomorrow and full time classical music these days.) Do you think I overbuilt the machine? At least I don't run the virtual machines all the time. {O,o}

Dymo labels? Honey, I used pieces of paper and tape back in the day. I'm not quite as old, and clearly not nearly as far into mental decay, as nominal the President of the US. But, I do think the Dymo company is still around making label tools. Lots of other companies make them, too.

{^_^} Joanne "quite crazy"

fventuri commented 2 years ago

Happy birthday Joanne! I wish you a wonderful day tomorrow (and the next 365 days, and the next 50 years)!

I do love classical music too (WJCT-HD2 when in the car, otherwise I stream WQXR now that I work from home).

I use Linux 99% of the time but, if I remember correctly, I don't think SDR Console uses ExtIO_sddc.dll (but I might be wrong); I also think that Simon Brown packages some version of the firmware in the whole SDR Console install file. If these assumptions are right (and Oscar probably knows better), then these changes would have to be somehow included in a new version of SDR Console in order for you to be able to see them.

Franco

ms-jdow commented 2 years ago

Indeed, Simon has his own driver code embedded in his software. So the solution would likely have to use a piece of memory within the hardware. That's why I was hoping the image went into eeprom or something like that. The other somewhat ugly solution that came to mind is use libusb's features to get the USB path name for the dongles and make them unique that way. But if they get changed to other ports at some time that could become awkward. I also noticed in the past that there is no guarantee the enumerations will always be in the same order, at least with rtlsdr dongles.

How many of the available efuse locations locations are unused? These are write once, aren't they? Or are they a form that can be healed a limited number of times?

BTW - it is KUSC that is 75. I predate it.

{^_^}

ik1xpv commented 2 years ago

Joanne, Happy Birthday from Italy !!!

The devices BBRF103, .., RX888 have no hardware eeprom connected to FX3 while the FX3 eFuses seem difficult to use. see at pag 47 of Tech manual 2019 https://www.cypress.com/file/134661/download - BootROM-A 32 KB ROM region that is preprogrammed with the FX3 device bootloader. The bootloader implements multiple boot modes such as USB boot, I2C boot, SPI boot, and GPIF boot. The desired boot mode is selected through a set of pin straps. This memory region is not accessible to FX3 user applications. In the forum: https://community.infineon.com/t5/USB-Superspeed-Peripherals/instruction-on-how-use-eFuse-on-FX3/m-p/45611

We have to think a solution to store Serial Number in hardware. It should be field programmable in the existing devices in the field. :-) ? A camera to read the Dymo label :-) .,, a patch to the flash image ?

On a different path I would try to add to ExtIO_sddc.dll the possibility to manually select one device when two are present. Just to allow experimenting two SDR on the same hardware with HDSDR, while we arrive to the better SN solution. When there is a single device connected nothing changes

Oscar

ms-jdow commented 2 years ago

From the looks of things I could conceivable find myself hooking a totally different device that uses the same boot mode to my computer with both it and the RX888 getting the same code loaded to them. Don't the folks at Cypress have provision for this? I'm rather gobsmacked.

{O.O}

ik1xpv commented 2 years ago

The Cypress boot-loader is designed for FX3 evaluation and development stage and it's present in every FX3 chip. Commercial devices use custom boot and/or external eeprom or flash with the code.

ik1xpv commented 2 years ago

Pull request two devices manual selection #210 is my tentative code If someone has two devices (can be different type ie BBRF103 RX888, RX888mkII ) please download the compiled code from the extio-package in Artifacts in the bottom of the page: https://github.com/ik1xpv/ExtIO_sddc/actions/runs/1377858810

Extract the archive in a directory with HDSDR.exe programs. Connect the two sdr to the computer, Run a first instance of HDSDR and select the first device. Run a second instance of HDSDR and select the second device. The order is the same at every run till the devices are cabled to the same USB ports. With a single device the code behavior should not ask for device selection and run as master branch. At power off HDSDR remember last settings.

Oscar

ms-jdow commented 2 years ago

As given it works. Now if you are on a machine that is not painful to reboot disconnect both,. boot, connect the two noting the order you used. See how this solution works. Now reboot and connect the two in the opposite order but to the same wires. Does 1 stay with 1 and 2 with 2? That would be the first goal. The second goal would be to have this work every time if you reverse the wires - as in connect to any available USB port and have it work.

And just to be obnoxious - play with three boxes.

{^_-}

ik1xpv commented 2 years ago

Thanks for report. The trick uses the Cypress ID devices numbering order from DeviceCount in CyAPI. The SDR hardware look the same at boot time. The advantages of this is to keep using the experimental PID/VID of Cypress and certified driver and not require an external EEPROM or Flash, This post https://community.infineon.com/t5/USB-Superspeed-Peripherals/About-eFuse-of-CYUSB3014/m-p/154662/highlight/true#M14745 describes a simple way to modify boot PID/VID but requires the external eeprom anyway.

ms-jdow commented 2 years ago

Changing the boot VID/PID might be possible. But, that gives you a practical range for identification that is extremely small.

A .inf file and associated "stuff" could be crafted. But, mix and match with friends is not really possible. And selling a modified unit becomes impractical. That is why I was looking for even one BYTE of eeprom or similar memory that can be modified by something like my RTLTool or the rtlsdr "rtleeprom" tools. Absent that it sounds like enumeration order has to settle the day. That is better than nothing but VERY easy to corrupt by accident. (Pull unit zero and plug it back in. Does unit 1 drop to 0 and the unplugged unit become 1 when plugged in - or does it get 2 or....?

Adding a tiny eeprom chip (or one big enough for the driver image plus a little extra) is arguably the right solution. But there are so many units out there now that this is not a feasible solution even if it is good and correct.

{^_^}

ik1xpv commented 2 years ago

I made some update #210 https://github.com/ik1xpv/ExtIO_sddc/actions/runs/1389428392 The number assigned to FX03 device depends on enumeration on this PC. So if you keep devices connected to the same port they will use always the same number. Test report please :))

ms-jdow commented 2 years ago

Please give me a day or two. I am ripping up some code in something for my partner so I can adapt to some new command parsing. I'll also look at the code to see if I agree with it. This sounds like one of the methods of adaptation I mentioned. There is one annoying condition under which it fails.

If you have a device plugged in and then add a device to a port that will be found earlier in the boot sequence it will still appear second until after the next reboot, perhaps only after the next full power off reboot. (And that is something I REALLY hate to do because of the "cluttered" way I use my machine. Getting it all back in MY order is a PITA.)

Are there any GPIO pins on a chip that can be reached and could be polled in SW? Some jumpers could set them. And if the pins are "floating" presently adding jumpers is feasible. MKIII coming up?

{^_ ^}

ik1xpv commented 2 years ago

Thanks, We are in no rush. :-) The file https://github.com/ik1xpv/ExtIO_sddc/blob/master/HWSDRtable.h list the different GPIO configurations allocated on different hardware. I'm the author of BBRF103 and HF103 while RX888 and RX888mk2 are by Justine and Howard. I have no knowledge of any other new hardware coming soon. It is difficult to add jumper to small SMD hardware.... Oscar

ms-jdow commented 2 years ago

Lookee lookee lookee at what I just discovered.. The attached image is from the properties pages for the two units. There are some VERY different numbers present. That should uniquely identify the beasties. Is that the number you are working with? If so, I guess that number is not going to stay if you change USP ports.

The interesting thing is that one of my boxes (RX888 MK II) maintains it's ID through an unplug to plug in cycle. The other does not;but, it gets the same ID every time. This is getting fascinating.

{^_^}

fventuri commented 2 years ago

Joanne, perhaps it's just me, but I don't see any image attached to your comment above.

Franco

ik1xpv commented 2 years ago

Hi, I made a try with devcon.exe https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon

I disconnected the two Cypress FX3 USB BootLoader Devices and exchange the cables The numbers depends on the USB ports. They do not depends on Fx3 devices (is we use the internal rom boot loader ! test file : devcon.txt

I think that CyAPI.lib uses the same port order and it does not change if we uses the same USB ports connection (?)

Oscar

ms-jdow commented 2 years ago

Try again RX888 IDs :

{^_^}

ik1xpv commented 2 years ago

Thanks Joanne,

The Device Instance path or Device Instance ID https://docs.microsoft.com/en-us/windows-hardware/drivers/install/device-instance-ids is persistent across system restarts. The Instance ID https://docs.microsoft.com/en-us/windows-hardware/drivers/install/instance-ids is a device identification string that distinguishes a device from other devices of the same type on a computer. An instance ID contains serial number information, if supported by the underlying bus (NO in our today code), or some kind of location information (YES we are here).

I connected two SDRs to the PC. I run two instances of HDSDR. I run devcon and I get _... c:\Program Files (x86)\Windows Kits\10\Tools\x64>devcon listclass USB Listing 15 devices in setup class "USB" (Controller USB (Universal Serial Bus)). ... USB\VID_04B4&PID_00F1\5&5E31287&1&6 : Cypress FX3 USB StreamerExample Device USB\VID_04B4&PID00F1\5&5E31287&1&8 : Cypress FX3 USB StreamerExample Device ... Then I close the HDSDR apps disconnect the SDRs exchange the cable/USB ports. Run HDSDR again. devcon now shows: _c:\Program Files (x86)\Windows Kits\10\Tools\x64>devcon listclass USB Listing 15 devices in setup class "USB" (Controller USB (Universal Serial Bus)). ... USB\VID_04B4&PID_00F1\5&5E31287&1&6 : Cypress FX3 USB StreamerExample Device USB\VID_04B4&PID00F1\5&5E31287&1&8 : Cypress FX3 USB StreamerExample Device .. c:\Program Files (x86)\Windows Kits\10\Tools\x64> The IDs depend only on the used port and do not identify the specific device connected (they are the location information as we have no Serial Numbers on the devices). This is the information used in CyAPI.lib to identify many devices of the same kind connected to the pc, The pull #210 tries to use it to identify two path on the same pc

Ciao, Oscar

fventuri commented 2 years ago

Oscar, I finally found some time to look at page 47 of the FX3 tech manual 2019 (the document you referred to in the comment a few days ago), and the two registers that contain the unique FX3 id at memory locations 0xE0055010 and 0xE0055014 (see here: https://community.infineon.com/t5/USB-Superspeed-Peripherals/Unique-Id-Registers-in-CYUSB3014/m-p/201271) are not in the BootROM region (which begins at 0xF000000), but in the MMIO register space (from 0xE0000000 to 0xEFFFFFFF), which is described as follows:

MMIO-The register space that holds all the configuration and status registers implemented by all the blocks on the FX3 device. While a total memory region of 256 MB has been allocated for the registers, most of this memory is unused and unimplemented. Refer to the chapters on each of the FX3 hardware blocks for information on the registers corresponding to those blocks.

and therefore you should be able to read them and use them to create a unique serial number for each BBRF103, HF103, RX-888, etc

Looking at the code in this example (https://community.infineon.com/t5/USB-Superspeed-Peripherals/FX3-Unique-ID-is-same-for-more-than-one-device/m-p/115063/highlight/true#M10249), it should be as easy as adding these two lines to the SDDC firmware (at least to try to see what they print out):

                status = CyU3PReadDeviceRegisters((uvint32_t *)0xE0055010,2,ID);
                CyU3PDebugPrint(4,"\r\n Read device register %d,0x%x,0x%x\n",status,ID[1],ID[0]);

Ciao from Florida, Franco

ik1xpv commented 2 years ago

Franco, YES ! That's a very good news ! Thanks! :-)) I like the message in your forum link: There will be a 64bits unique ID for each die of FX3. You can read these bits from the address location 0xE0055010 In the next week I will dig in FX3 firmware adding serial number reading. I will take some time since I have to refresh my memory on Arm :-) I like the fact that possibly it is not required to program any device in the field as the SN is just there ! ! !

Have you All a nice weekend, Ciao Oscar

ms-jdow commented 2 years ago

Ooooh - I like this Franco guy. {^_-} That sounds very very promising. Thank you sir!

{^_^}

fventuri commented 2 years ago

Oscar, Joanne, glad to be able to help! (and my apologies for the confusion about KUSC's birthday and yours)

Tonight, following Cypress forums suggestions here: https://community.infineon.com/t5/USB-Superspeed-Peripherals/FX3-Device-Name/m-p/287956 , I made a few changes to the firmware file USBdescriptor.c so that it should return this unique FX3 id as the serial number (the modified file is attached below).

All I could check here is that the file with the changes compiles without errors (I unrolled the loop that assigns the 16 hex digits of the serial number; if you prefer, those lines can be changed to a couple of 'for' loops; in 'normal' C one would have used 'snprintf()', but I don't think it is an option here because it allocates heap memory).

Please take a look at the changes, and, if you feel like trying it, let me know how it goes.

Franco

USBdescriptor.c.gz

ms-jdow commented 2 years ago

Franco, your comment raises a question for Oscar. If you are using Visual Studio 19 why not use its make facility and compiler? It would save putting extraneous "stuff" on your machine? (That's one of the reasons I've not gone in and tinkered myself. I may still do so and make a proper project. DLLs and I are usually good friends.)

{^_^}

fventuri commented 2 years ago

First of all, I am an old school Linux/vi/make kind-of guy, so no VS, Eclipse, IntellJ at my house :-)

This said, I used the instructions in the ExtIO_sddc README (https://github.com/ik1xpv/ExtIO_sddc#build-instructions-for-firmware) to build the firmware (which was just typing 'make', since I already have he ARM toolchain here), and I was able to compile it (I had to fix one very minor thing in 'rx999.c', but that is unrelated).

So I have the modified firmware here, but I don't own any of these SDRs; that's why I said earlier that I can only make sure it compiles.

As per the thing with 'sprintf()', yesterday I was reading this thread on the Cypress FX3 community forums (https://community.infineon.com/t5/USB-Superspeed-Peripherals/FX3-Fail-to-call-sprintf-function-for-float-on-C-project/m-p/272300), and it made me think that perhaps using 'sprintf()' to just convert 16 hexadecimal values to characters is overkill, and that's the reason of the approach I took in the modified USBdescriptor.c

Franco

ik1xpv commented 2 years ago

Welcome on board Joanne ! I like to play with DSP code. The repository comes from to the ideas and had work by Hayati Ayguen, Howard Su , Franco Venturi and me. Howard built also the automate workflow They tried to teach me how to use Github. I am fond of it and I thank them for their patience. I suggest you to fork the repository to exercise and pull your requests. The readme describes the environment setup and it's the starting point as Franco said. I use VS2019 as compiler but I compile the Arm code in Linux environment. I personally use GihHub desktop or direct Github in the browser.

Franco, yes! we could also change the Product name to the specific hardware found I'm testing it ..

FriendlyName="Cypress FX3 USB StreamerExample Device" Manufacturer="sdr-prototypes.blogspot.com" _// <- I think of "Open Source at GitHub\,,," ? ?_ Product="BBRF103" _// or RX888, RX888mk2 , HF103 ...._ SerialNumber="012345678901" .... Oscar

fventuri commented 2 years ago

Joane, welcome on board from me too! I apologize if my earlier comment about Linux was harsh and snarky - I really appreciate working with Oscar and the others and all the things I learned from them, and you are most welcome to join us!

Oscar, I like your ideas; I would also like to see if it is possible to get away from Cypress' own USB VID and PID, that we are probably not supposed to be using at this point. On that regard, I found this email from a bit ago:

I also suggest that we take the opportunity of the new firmware to 'move out' from Cypress 'streamer example' PID/VID in the USB descriptor, since according to Cypress you are not supposed to use it (https://community.cypress.com/docs/DOC-12682).

I did some quick research and I found a few options:

request a free USB product id from Openmoko (see here: http://wiki.openmoko.org/wiki/USB_Product_IDs); they are free for open source projects

another similar option is pid.codes (https://pid.codes/)

purchase one from MCS (https://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1) - this would allow for commercial development too, but you may want to read the disclaimer in that page first, about USB-ORG stance on those PID/VIDs

finally one (with deep pockets!) could buy a whole USB PID from USB-ORG (it allows for 64k VIDs, similar to a class B Internet network), but I think those cost $6k or something like that

This was a year or so ago; it is possible that there are more and different options now. Since this is an open source project, perhaps we should look at applying with Openmoko or pid.codes, since they are free.

Franco

ik1xpv commented 2 years ago

Franco,

The advantage of using Cypress VID/PID is also in use of Cypress certified driver. At development stage as we are now it seems to me a correct use with the limit Cypress states " If the Cypress VID is used for an end product, then many customers could use the same VID, which could cause a malfunction because an end product may bind to an incorrect driver " The fact that we have no eeprom forces us to use the VID/PID Cypress for the "Cypress FX3 BootLoader Device" anyway before we could load a custom VID/PID image in ram, It seems to me that the different VID/PID is the path to follow for someone that make a product with eeprom to house the firmware of FX3 or a custom boot. Only in this way it will be free from collision with the "Cypress FX3 BootLoader Device",

At the moment I like to test your ideas and code. I plan to have some test result middle of next week as I will be offline tomorrow.

Oscar

ik1xpv commented 2 years ago

Update I made a rapid test of your serial number code on two devices. All ok ! Here the Cypres USB control center output Device 1 FriendlyName="Cypress FX3 USB StreamerExample Device" Manufacturer="sdr-prototypes.blogspot.com" Product="RX888" SerialNumber="0008012400431D31" Device 2 FriendlyName="Cypress FX3 USB StreamerExample Device" Manufacturer="sdr-prototypes.blogspot.com" Product="RX888mk2" SerialNumber="0009023200531716"

I plan commit on Tuesday or Wednesday. Ciao Oscar

fventuri commented 2 years ago

That's great news, Oscar!

At this point it might be a good idea to get in touch with Simon Brown of SDR Console to ask him if he can include the new release of the firmware with the unique S/N in the next version of his software.

Franco

ms-jdow commented 2 years ago

I figure once it is known working we can bug Simon. He's in a big push at the moment so I'd want things to be as easy to drop in as possible. I am also pestering him to add 128 Msps or user entered sample rate as an even better deal. (That might fix another very subtle bug he has.)

{^_^}

ms-jdow commented 2 years ago

I guess now it might be appropriate to see if we can reach out to the system random number generator, if I can find it, and see if we can use that if those registers are in their default setting state. I believe the key to this is "errno_t rand_s(unsigned int* randomValue);" which requires this in the file's include list:

define _CRT_RAND_S

include

I wonder if that can be used to generate a relatively unique ID (64 bits instead of 128) that we can use for the serial number. (I rather like the rtlsdr dongles. I can use fairly long informative strings such as "RTLSDR on Discone",)

Is that USBdescriptor.c file already a part of the project or is it from an example?

{^_^}

fventuri commented 2 years ago

Joanne, I am not sure what you mean when you say "if those registers are in their default setting state", since according to this post on Cypress community forums (https://community.infineon.com/t5/USB-Superspeed-Peripherals/Unique-Id-Registers-in-CYUSB3014/m-p/201273/highlight/true#M20119):

There will be a 66bits unique ID for each die of FX3. You can read these bits from the address location 0xE0055010.

(they actually meant 64 bits, not 66)

As per the file USBdescriptor.c, the original (before my modifications) comes from Oscar's project, and you can find it here: https://github.com/ik1xpv/ExtIO_sddc/blob/master/SDDC_FX3/USBdescriptor.c

Franco

ms-jdow commented 2 years ago

Ah - so it is read only and precisely what we want for a serial number. I have not gotten the chip's addressing scheme into my head, yet. I see one of the responders to that thread was worried about the bit order and the correct way to express the unique ID. I suppose that matters if you want to complain about a specific chip to the Cypress folks. Otherwise it's just as unique either way.

{^_-}

ik1xpv commented 2 years ago

Joanne, If you have time and access to two SDRs please download and run the compiled code at https://github.com/ik1xpv/ExtIO_sddc/actions/runs/1417405256 or compile the code at #210 In principle it should be able to find up to 4 FX3 devices connected to the PC and select the one to be used. If there is a single FX3 no selection is required.

Oscar

ms-jdow commented 2 years ago

This is what I got:

The numbers are interesting. Another test coming. This is with one of them plugged into a different port.

It seems to work properly. Thank you! I'll pass the critical addresses along to Simon.

As a side issue - what all is involved in adding higher sample rates to the old RX666/RX888 code?

{^_^}

ik1xpv commented 2 years ago

Joanne, Thanks for report. I 'm still digging in the code to try to improve power up discovery of FX3 BootLoader devices. Simon is informed. The RX888 has the same sampling rate capabilities of RX888mk2, I do not know of RX666 I imagine they cloned BBRF103 architecture. I do not know the hardware limit nor how the hardware is detected from today software. HF103 prototype uses a fixed low noise xtal reference at 64 MHz that is not programmable.

Oscar

ms-jdow commented 2 years ago

I think you are saying the step from 888 to 888 MK 2 may not be a simple thing for Simon to code. (I had this insane notion of doing something like monitoring all ham bands for ALE traffic using SDR Radio and a huge number of ALE decoders. It's just to say "it can be done" even if it is silly because you almost always know what set of bands just aren't going to work and which might show some sporadic E skip.)

{^_-}

ik1xpv / ExtIO_sddc

Two devices on the same system at the same time #209

define _CRT_RAND_S

include