Thanks Brian.
At the moment reading the parallel TS is not a problem. I did consider using a com port but initially I am trying to make it behave as close to an FTDI device as possible, that way it has the best chance of working with existing software without needing major changes. It is also an excuse to learn more about how USB operates.
Colin.
Minitiouner
Forum rules
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
Re: Minitiouner
A serial TS is much easier to make a PCB for though and dual TS may be popular.
Mike
Mike
Re: Minitiouner
If you have the pins spare, perhaps the second TS could be wired as a 3 pin serial, so that a future version of OpenTuner or other software could access it.
The COM port method isn't a very good solution, as you have to filter out all the print statements from LongMynd, which also use it. I'm hoping to use your USB endpoint software in a future version of PicoHub.
Brian
The COM port method isn't a very good solution, as you have to filter out all the print statements from LongMynd, which also use it. I'm hoping to use your USB endpoint software in a future version of PicoHub.
Brian
Re: Minitiouner
Success!
After much frustration, debugging and reading of data sheets I now have the Pico working as a replacement for the FTDI module. I still have some more tweaking and tidying of the code to do but I am now happy with the results.
So far it has successfully worked with all the signals I have tried on QO100 including the beacon. Now I have it working I will try it at higher sample rates on a local signal. I suspect that it won't go much higher as it is getting close to saturating the USB bus. Probably something like 2000 will be the upper limit.
Currently it works with no changes to the longmynd code. The Ryde front end does need a change to the device detection logic, mainly because the Pico does not emulate the FTDI EEPROM. I have done a hack to bypass the device detection and then Ryde works OK. I am sure a tidier solution can be found.
Likewise Opentuner does not run yet because it uses the windows FTDI drivers. Again I am sure something can be done there to get it working. Windows is recognising the Pico as if it was a FTDI device but I am sure the drivers will not be happy. It may be necessary to use Zadig to provide a suitable driver. In the longer term it probably makes more sense to give the Pico it's own VID/PID rather than trying to use the FTDI ones.
Colin G4EML
After much frustration, debugging and reading of data sheets I now have the Pico working as a replacement for the FTDI module. I still have some more tweaking and tidying of the code to do but I am now happy with the results.
So far it has successfully worked with all the signals I have tried on QO100 including the beacon. Now I have it working I will try it at higher sample rates on a local signal. I suspect that it won't go much higher as it is getting close to saturating the USB bus. Probably something like 2000 will be the upper limit.
Currently it works with no changes to the longmynd code. The Ryde front end does need a change to the device detection logic, mainly because the Pico does not emulate the FTDI EEPROM. I have done a hack to bypass the device detection and then Ryde works OK. I am sure a tidier solution can be found.
Likewise Opentuner does not run yet because it uses the windows FTDI drivers. Again I am sure something can be done there to get it working. Windows is recognising the Pico as if it was a FTDI device but I am sure the drivers will not be happy. It may be necessary to use Zadig to provide a suitable driver. In the longer term it probably makes more sense to give the Pico it's own VID/PID rather than trying to use the FTDI ones.
Colin G4EML
Re: Minitiouner
Great stuff.
Which SDK / language are you using? I'm sure I was getting much more than 2000 using the COM port and the C SDK.
Brian
Which SDK / language are you using? I'm sure I was getting much more than 2000 using the COM port and the C SDK.
Brian
Re: Minitiouner
Hi Brian,
I am using the Arduino IDE to develop this for convenience but I am using the C SDK. The USB is being driven at register level using the RPI Low Level C example code so in practice the Arduino environment and the C SDK is not really being used much. Each USB transfer is handled completely by the USB peripheral hardware, you just load its data buffer with 64 bytes and tell it to go, it then interrupts when it has completed the transfer.
The limitation looks like it is down to the transfer speed of the USB. I have a 'scope pin I set when a transfer is requested and I reset it when it completes. That time is all down to the USB hardware controller, there is no software involvement at the Pico end. Obviously the response time of the Longmynd end also plays a part in this. The 'Scope shows that when receiving the QO-100 beacon about 50% of the time available is used by the TS transfers. So It might push to an SR of 3000.
I hope to give the serial TS mode a try later today or tomorrow. The PIO code is almost the same! Just changing 'In Pins,8' to 'In Pins,1' . Changing the NIM mode is a bit more involved but I can see where it is done in the longmynd code so it should be easy enough to patch.
I notice that when receiving with Longmynd the TS1 port is also outputting data, it looks like the same data as TS2, if so it might make it easy to experiment with a twin TS solution.
Colin.
I am using the Arduino IDE to develop this for convenience but I am using the C SDK. The USB is being driven at register level using the RPI Low Level C example code so in practice the Arduino environment and the C SDK is not really being used much. Each USB transfer is handled completely by the USB peripheral hardware, you just load its data buffer with 64 bytes and tell it to go, it then interrupts when it has completed the transfer.
The limitation looks like it is down to the transfer speed of the USB. I have a 'scope pin I set when a transfer is requested and I reset it when it completes. That time is all down to the USB hardware controller, there is no software involvement at the Pico end. Obviously the response time of the Longmynd end also plays a part in this. The 'Scope shows that when receiving the QO-100 beacon about 50% of the time available is used by the TS transfers. So It might push to an SR of 3000.
I hope to give the serial TS mode a try later today or tomorrow. The PIO code is almost the same! Just changing 'In Pins,8' to 'In Pins,1' . Changing the NIM mode is a bit more involved but I can see where it is done in the longmynd code so it should be easy enough to patch.
I notice that when receiving with Longmynd the TS1 port is also outputting data, it looks like the same data as TS2, if so it might make it easy to experiment with a twin TS solution.
Colin.
Re: Minitiouner
Hi Colin,g4eml wrote: ↑Tue Jan 30, 2024 10:41 pmCurrently it works with no changes to the longmynd code. The Ryde front end does need a change to the device detection logic, mainly because the Pico does not emulate the FTDI EEPROM. I have done a hack to bypass the device detection and then Ryde works OK. I am sure a tidier solution can be found.
If there is a way I can detect the difference between this and a genuine FTDI module I can set Ryde up to do that first and not try and read the EEPROM in that case. Feel free to message me and we can work out how to get these working together.
Are you thinking of porting this to Knucker at some point eventually? If that is the case you will need a way for software to detect which device it is.
Tim
Re: Minitiouner
I mistook 2000 as the data rate rather than the symbol rate, so you have enough bandwidth already for the beacon and something else.
The PIOs are really neat. It's surprising to find them on such a cheap chip.
Most of the NIM registers are taken from the stv0910_regs_init.h file and not modified, so that would be the place to change them.
The duplicate TS output is probably because the stv0910 is in single TS mode. It took a while to get both TS's out in WinterHill, even though the two demodulators were receiving different signals. There are a few register settings to change for dual TS mode and lots of changes in stv0910.c and stv6120.c, but they will be in the WinterHill and OpenTuner softwares.
Brian
The PIOs are really neat. It's surprising to find them on such a cheap chip.
Most of the NIM registers are taken from the stv0910_regs_init.h file and not modified, so that would be the place to change them.
The duplicate TS output is probably because the stv0910 is in single TS mode. It took a while to get both TS's out in WinterHill, even though the two demodulators were receiving different signals. There are a few register settings to change for dual TS mode and lots of changes in stv0910.c and stv6120.c, but they will be in the WinterHill and OpenTuner softwares.
Brian
Re: Minitiouner
Hi Tim,
I only had a quick look at your Ryde code but I think you are reading the Interface descriptors of the devices by reading the EEPROMS directly with an FTDI specific library. That seems to be a vendor specific thing and FTDI don't publish how it works so it would be difficult to emulate.
The USB will already have enumerated the device and read it's interface descriptors as part of that process so there should be a generic way to get them from the OS which should work with any device.
It would then be easy to have unique Interface descriptors for minitiouner and knucker in the Pico.
There is also the question of what VID/PID to use for the device. At the moment I am using the FTDI ones for compatibility but in the longer term that is probably not a good idea.
Once I get on a bit further I will contact you and work out a plan.
Colin G4EML
I only had a quick look at your Ryde code but I think you are reading the Interface descriptors of the devices by reading the EEPROMS directly with an FTDI specific library. That seems to be a vendor specific thing and FTDI don't publish how it works so it would be difficult to emulate.
The USB will already have enumerated the device and read it's interface descriptors as part of that process so there should be a generic way to get them from the OS which should work with any device.
It would then be easy to have unique Interface descriptors for minitiouner and knucker in the Pico.
There is also the question of what VID/PID to use for the device. At the moment I am using the FTDI ones for compatibility but in the longer term that is probably not a good idea.
Once I get on a bit further I will contact you and work out a plan.
Colin G4EML
Re: Minitiouner
I'm a bit late to this conversation, but great work Colin! I'd be keen to get involved to get this working with OT (and its newer cross platform version). I'll send you a message 
Edit: looks like I can't send you a message. Feel free to send me a message.
T
Edit: looks like I can't send you a message. Feel free to send me a message.
T