We know that the more we go into time the less CM108 or the like chips are going to be available.
We have problem with hickups on the usb driven interface and while SBC are getting more powerfull we still suffer from small cuts in audio.
The production of the voter boards are stopped and making the original one is not that as easy as many of the component are going into obsolescence.
I was thinking about this and I started to think of what type of device could do a nice audio interface that could also have enough power to do DSP for squelch and tone decoding and have i/o that can be driven in real time to control the repeaters.
And I got that silly idea that they just did it with the MMDVM STM32 digital controler.
They added voice to all the stm32 based MMDVM.
Those are powerfull enough to decode digital voice. and they encode them very well. Now if we could use the same chips but not with all the digital stuff. Just the analog with the possibility to do do dsp like on usbradio ( but on the chip, not on asterisk) and at the same time and not use a USB method of transfert,
but use IP and maybe use the USRP protocole as a base of communication or even the voter IP method.
That’s nice - the STM could do the CTCSS generation and detection.
But the connection to the host computer would be by USB - no? That is where the problems are right now. So you would still have those problems.
Of course, I suppose it could use a different format where perhaps larger chunks of data are transferred at one time. Or the connection could be by SPI? That might make it RPI-specific though.
the stm32 can drive a network card directly and could send all the data by IP and not USB or it could do as the ADAM-PLUTO do and simulate a network card by USB. That is something that could drain the processor a lot on the other side.
That’s nice - the STM could do the CTCSS generation and detection.
But the connection to the host computer would be by USB - no? That is where the problems are right now. So you would still have those problems.
Of course, I suppose it could use a different format where perhaps larger chunks of data are transferred at one time. Or the connection could be by SPI? That might make it RPI-specific though.
I am no coder. I am more a problem solver. We know that the more we go into time the less CM108 or the like chips are going to be available. We have problem with hickups on the usb driven interface and while SBC are getting more powerfull we still suffer from small cuts in audio. The production o…
I like your thoughts about this. It kinda’ lines up with my post about Pi-Star. A Zum modem like Pi hat would be a killer hotspot. I’d also like to see an appliance (like the RTCM) where I don’t have to put a Pi at a very remote repeater site.
If the firmware of the rtcm/voter board would be kind of compatible or transferable to the stm32 I would try to make it. As we have the source… those thing are so damn useful
I like your thoughts about this. It kinda’ lines up with my post about Pi-Star. A Zum modem like Pi hat would be a killer hotspot. I’d also like to see an appliance (like the RTCM) where I don’t have to put a Pi at a very remote repeater site.
But I just downloaded the build environment for the stm32f7
If I can import the project in there and then “try” to fix the error in compilation, it could at least be a kind of step.
If that can be done I am ordering the cube development board and I will try to at least do the alpha testing.
After all the stm32f7 and the dsPIC are from micho-chip… I could be a dreamer. But I will try.
If the firmware of the rtcm/voter board would be kind of compatible or transferable to the stm32 I would try to make it. As we have the source… those thing are so damn useful ··· (click for more details)
What about using the beagle bone series of boards for this? Both the black and tireless boards have dual real-time processors on board, and the new beagle ai has a dsp coprocessor, 4 real-time units, and a couple arm m4 coprocessors. One board that does it all with the bonus that there is a repeater/remote base controller that it plugs into so one neat and tidy package that’s mountaintop ready and tested does it all for you.
But I just downloaded the build environment for the stm32f7
If I can import the project in there and then “try” to fix the error in compilation, it could at least be a kind of step.
If that can be done I am ordering the cube development board and I will try to at least do the alpha testing.
After all the stm32f7 and the dsPIC are from micho-chip… I could be a dreamer. But I will try.
If the firmware of the rtcm/voter board would be kind of compatible or transferable to the stm32 I would try to make it. As we have the source… those thing are so damn useful
I like your thoughts about this. It kinda’ lines up with my post about Pi-Star. A Zum modem like Pi hat would be a killer hotspot. I’d also like to see an appliance (like the RTCM) where I don’t have to put a Pi at a very remote repeater site.
the stm32 can drive a network card directly and could send all the data by IP and not USB or it could do as the ADAM-PLUTO do and simulate a network card by USB. That is something that could drain the processor a lot on the other side.
That’s nice - the STM could do the CTCSS generation and detection.
But the connection to the host computer would be by USB - no? That is where the problems are right now. So you would still have those problems.
Of course, I suppose it could use a different format where perhaps larger chunks of data are transferred at one time. Or the connection could be by SPI? That might make it RPI-specific though.
But I just downloaded the build environment for the stm32f7
If I can import the project in there and then “try” to fix the error in compilation, it could at least be a kind of step.
If that can be done I am ordering the cube development board and I will try to at least do the alpha testing.
After all the stm32f7 and the dsPIC are from micho-chip… I could be a dreamer. But I will try.
If the firmware of the rtcm/voter board would be kind of compatible or transferable to the stm32 I would try to make it. As we have the source… those thing are so damn useful
I like your thoughts about this. It kinda’ lines up with my post about Pi-Star. A Zum modem like Pi hat would be a killer hotspot. I’d also like to see an appliance (like the RTCM) where I don’t have to put a Pi at a very remote repeater site.
the stm32 can drive a network card directly and could send all the data by IP and not USB or it could do as the ADAM-PLUTO do and simulate a network card by USB. That is something that could drain the processor a lot on the other side.
That’s nice - the STM could do the CTCSS generation and detection.
But the connection to the host computer would be by USB - no? That is where the problems are right now. So you would still have those problems.
Of course, I suppose it could use a different format where perhaps larger chunks of data are transferred at one time. Or the connection could be by SPI? That might make it RPI-specific though.
I’m no coder, I know just enough to create havoc But I just downloaded the build environment for the stm32f7 If I can import the project in there and then “try” to fix the error in compilation, it could at least be a kind of step. If that can be done I am ordering the cube development boar…