New hardware interface to replace URI-X and voter board

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 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.

Anyone have been thinking about this?

Pierre
VE2PF

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.

Food for thought.

Ken

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.

···

Le sam. 5 sept. 2020 à 10:11, Ken Jamrogowicz via AllStarLink Discussion Groups <noreply@community.allstarlink.org> a écrit :

Ken_Jamrogowicz
September 5

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.

Food for thought.

Ken


Visit Topic or reply to this email to respond.


In Reply To

Pierre_Martel
September 4

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…


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

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 :wink:

···

Le dim. 6 sept. 2020 à 14:53, Tim Sawyer via AllStarLink Discussion Groups <noreply@community.allstarlink.org> a écrit :

wd6awp ASL Admin
September 6

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.


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

The RTCM code is here:

and there is at least one person around here that is familiar with it.

I’m no coder, I know just enough to create havoc :wink:

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.

···

Le dim. 6 sept. 2020 à 18:52, Tim Sawyer via AllStarLink Discussion Groups <noreply@community.allstarlink.org> a écrit :

wd6awp ASL Admin
September 6

The RTCM code is here:

GitHub

AllStarLink/voter

Contribute to AllStarLink/voter development by creating an account on GitHub.

and there is at least one person around here that is familiar with it.


Visit Topic or reply to this email to respond.


In Reply To

Pierre_Martel
September 6

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 :wink: ··· (click for more details)


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

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.

Eric

Sent using SMTP.

···

On Sep 6, 2020, at 7:27 PM, Pierre Martel via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:

Pierre_Martel
September 7

I’m no coder, I know just enough to create havoc :wink:

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.

··· (click for more details)


Visit Topic or reply to this email to respond.


In Reply To

wd6awp ASL Admin
September 6

The RTCM code is here: and there is at least one person around here that is familiar with it.

Previous Replies

wd6awp ASL Admin
September 6

The RTCM code is here:

GitHub

AllStarLink/voter

Contribute to AllStarLink/voter development by creating an account on GitHub.

and there is at least one person around here that is familiar with it.

Pierre_Martel
September 6

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 :wink:

··· (click for more details)

wd6awp ASL Admin
September 6

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.

Pierre_Martel
September 6

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.

··· (click for more details)

Ken_Jamrogowicz
September 5

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.

Food for thought.

Ken


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

“the stm32f7 and the dsPIC are from micho-chip” Are you sure about that? I don’t think so.

Chuck

···

On Sun, Sep 6, 2020 at 9:27 PM Pierre Martel via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

Pierre_Martel
September 7

I’m no coder, I know just enough to create havoc :wink:

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.

Visit Topic or reply to this email to respond.


Previous Replies

wd6awp ASL Admin
September 6

The RTCM code is here:

GitHub

AllStarLink/voter

Contribute to AllStarLink/voter development by creating an account on GitHub.

and there is at least one person around here that is familiar with it.

Pierre_Martel
September 6

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 :wink:

wd6awp ASL Admin
September 6

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.

Pierre_Martel
September 6

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.

Ken_Jamrogowicz
September 5

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.

Food for thought.

Ken

Yeah you are right, not the same company. Looks like I was mixed in my ideas

···

Le lun. 7 sept. 2020 à 01:21, Chuck Henderson via AllStarLink Discussion Groups <noreply@community.allstarlink.org> a écrit :

Chuck_Henderson
September 7

“the stm32f7 and the dsPIC are from micho-chip” Are you sure about that? I don’t think so.

Chuck

··· (click for more details)


Visit Topic or reply to this email to respond.


In Reply To

Pierre_Martel
September 7

I’m no coder, I know just enough to create havoc :wink: 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…


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.