Projectgroep .540 - Gebruikersbijdragen [nl]

SDRAngel driven by Ollama LLM using MCP

2025-09-04T20:01:26Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the [https://www.claudemcp.com/ Model Context Protocol].

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRangel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows-11 laptop with WSL2 Ubuntu flavor (24.04).

'''Hardware recommendation''' Due to LLM 16 Gbyte memory

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

Example of the "man in the middle" confirmation popup what will be changed according to the knowledge of the LLM. The blue chat window was my request, the popup appears in the right top corner with the buttons "Cancel or Execute".

[[File: Mcp4.png]]

SDRAngel driven by Ollama LLM using MCP

2025-09-04T19:54:48Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRangel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows-11 laptop with WSL2 Ubuntu flavor (24.04).

'''Hardware recommendation''' Due to LLM 16 Gbyte memory

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

Example of the "man in the middle" confirmation popup what will be changed according to the knowledge of the LLM. The blue chat window was my request, the popup appears in the right top corner with the buttons "Cancel or Execute".

[[File: Mcp4.png]]

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:41:58Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows-11 laptop with WSL2 Ubuntu flavor (24.04).

'''Hardware recommendation''' Due to LLM 16 Gbyte memory

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

Example of the "man in the middle" confirmation popup what will be changed according to the knowledge of the LLM. The blue chat window was my request, the popup appears in the right top corner with the buttons "Cancel or Execute".

[[File: Mcp4.png]]

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:40:43Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows-11 laptop with WSL2 Ubuntu flavor (24.04).

'''Hardware recommendation''' Due to LLM 16 Gbyte memory

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

Example of the "man in the middle" confirmation popup what will be changed according to the knowledge of the LLM.

[[File: Mcp4.png]]

Bestand:Mcp4.png

2025-08-26T18:37:49Z

Pe2jko:

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:25:57Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows-11 laptop with WSL2 Ubuntu flavor (24.04).

'''Hardware recommendation''' Due to LLM 16 Gbyte memory

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:21:09Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL2 Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:20:16Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end [https://github.com/f4exb/sdrangel/wiki SDRangel]. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:19:28Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible] As this system is quite flexible it has the potential to become quite powerfull. The Ollama local LLM with 1.7b Qwen model is quite responsive, but it can take a second before the tokens are written when it needs to report the status or a list of commands. The results are not always 100% but with fine tuning and create perhaps some pre-sets which can be called from the LLM if he knows that they exist would make it very easy to operate. If you are interested and have ideas let me know.

'73,JKO

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:13:22Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

The flow contains may debug (green nodes) to check it's payload input. Experiments can be done with other models with more parameters or models in the cloud [https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/ which are MCP compatible]

SDRAngel driven by Ollama LLM using MCP

2025-08-26T18:07:35Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

The Node-Red flow. The Red and purple nodes belong to the MCP server. The brown nodes are the API calls to SDRangel to make changes to the settings. Currently only 1 channel is implemented as proof. The other nodes are for default settings en a "man in the middle". As sometimes LLM decisions are not correct we need to verify which changes it is going to execute. Therefor a notification window will pop up asking you/me to approve or cancel the change requested by the LLM. The LLM can set all parameters at once or one per client request. It depends what is asked. If I ask "change freq to 100 Mhz and set gain to 12 Db" it will change 2 parameters for the current control set for SDRangel. If I ask "I would like to listen to commercial Braodcast Station Veronica , set optimum parameters" the LLM might set 5 or 6 parameters at the same time. As not always correct the "man in the middle" (you) can decide to execute or not.

[[File: Mcp3.png]]

Bestand:Mcp3.png

2025-08-26T17:58:39Z

Pe2jko:

SDRAngel driven by Ollama LLM using MCP

2025-08-26T17:55:47Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

Node-red mcp server have a specific registry node which will tell the LLM in what format it can request the server to provide more information. It is called a "JSON Schema". This is also a JSON file. The LLM will parse this file and as it also contains a description what a specific entry is repsonsible for the LLM decide what to return to the MCP server.

SDRAngel driven by Ollama LLM using MCP

2025-08-26T17:48:19Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{
{ "mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}
}

SDRAngel driven by Ollama LLM using MCP

2025-08-26T17:47:43Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples :

The MCP relay configuration is calling the MCP server running in Node-red. As this is a SSE oriented server and the bridge needs an "STDIO" communication the mcp-proxy is used. Therefore the JSON config for the bridge is simpel

{ "mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://ip-address-node-red:8001/mcp",
"--transport=streamablehttp"
]
}
}
}

SDRAngel driven by Ollama LLM using MCP

2025-08-26T17:35:05Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- [https://nodered.org/docs/getting-started/windows Node-Red]''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- [https://github.com/sparfenyuk/mcp-proxy mcp-proxy]''' in Ubuntu

'''- [https://ollama.com/download/windows Ollama with model Qwen3:1.7b]''' in Windows

'''- [https://github.com/f4exb/sdrangel SDRangel]''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-26T17:31:57Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- [https://github.com/jonigl/ollama-mcp-bridge Ollama-mcp-bridge]''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:55:44Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was also discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel. Client requests like "Setup Pluto on channel 10 to transmit to QO-100 on 333 kilosamples", or "I would to listen to Radio Veronica on FM band, setup best parameters" or "Scan 20 meter band SSB mode and show map", or "increase volume" as possible client requests.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- Ollama-mcp-bridge''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:48:13Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard 2 Chat.

'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- Ollama-mcp-bridge''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:45:04Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Example of simpel client commands to SDRangel:

[[ File:Mcp1.png ]]

Client interaction example :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- Ollama-mcp-bridge''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:43:39Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Voorbeeld van simpele besturing van parameters:

[[ File:Mcp1.png ]]

Voorbeeld van een vraag aan SDRangel :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- Ollama-mcp-bridge''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

----

High level process:

The MCP bridge connect to MCP server provided by Node-Red (mcp-server node), and collect all published tools and provide this information to Ollama. Node-red Chat ( Dashboard-2 UI Chat node) client type a question or command in natural language. Chat completion request is send to the bridge, the bridge forward to Ollama. If the Language model decide to call the published tools node-red MCP server node will receive it and specific operation can be performed for example sending an API command to SDRangel. Feedback of the MCP server response will be forwarded again to Ollama LLM and formulate an answer or summarize the action performed and return it to the client.

Specific and examples : TBD

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:29:57Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Voorbeeld van simpele besturing van parameters:

[[ File:Mcp1.png ]]

Voorbeeld van een vraag aan SDRangel :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''- Node-Red''' in Windows

'''- Ollama-mcp-bridge''' in Ubuntu

'''- mcp-proxy''' in Ubuntu

'''- ollama with model Qwen3:17b''' in Windows

'''- SDRangel''' in Windows

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:28:59Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Voorbeeld van simpele besturing van parameters:

[[ File:Mcp1.png ]]

Voorbeeld van een vraag aan SDRangel :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''Node-Red''' in Windows

'''Ollama-mcp-bridge''' in Ubuntu

'''mcp-proxy'''' in Ubuntu

'''ollama with model Qwen3:17b''' in Windows

'''SDRangel''' in Windows

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:28:28Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Voorbeeld van simpele besturing van parameters:

[[ File:Mcp1.png ]]

Voorbeeld van een vraag aan SDRangel :

[[ File:Mcp2.png ]]

----

Detailed explanation and system flows will be discussed here. Following components are used :

'''Node-Red''' in Windows
'''Ollama-mcp-bridge''' in Ubuntu
'''mcp-proxy'''' in Ubuntu
'''ollama with model Qwen3:17b''' in Windows
'''SDRangel''' in Windows

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:19:21Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----
Voorbeeld van simpele besturing van parameters:

[[ File:Mcp1.png ]]

Voorbeeld van een vraag aan SDRangel :

[[ File:Mcp2.png

Content :

Bestand:Mcp2.png

2025-08-25T19:17:53Z

Pe2jko:

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:15:30Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----

[[ File:Mcp1.png ]]

Content :

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:14:34Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

----

[File:Mcp1.png]

Content :

Bestand:Mcp1.png

2025-08-25T19:12:33Z

Pe2jko: voorbeeld

voorbeeld

SDRAngel driven by Ollama LLM using MCP

2025-08-25T19:00:05Z

Pe2jko:

SDRangel operated by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and operate the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

Content :

SDRAngel driven by Ollama LLM using MCP

2025-08-25T18:58:34Z

Pe2jko: Nieuwe pagina aangemaakt met 'SDRangel driven and controlled by Ollama Local Language Model using the Model Context Protocol. '''Info @''' joopk@hccnet.nl Experiment using an AI Local Languag...'

SDRangel driven and controlled by Ollama Local Language Model using the Model Context Protocol.

'''Info @''' joopk@hccnet.nl

Experiment using an AI Local Language model to control and drive the sophisticated signal analyzer front-end SDRangel. Controlling SDRangel while Talking/typing to it in natural language was the goal of this experiment. The system use different components which will be discussed/shown in this Wiki article.

Using AI in radio amateur world is a topic which was als discussed on the 49th International Amateur Radio Exhibition in Friedrichshafen. A lecture about AI Agents and Reasoning models was given by Jochen Berns, DL1YBL. This inspired me to experiment with MCP servers and Ollama trying to see how AI can help operate a rather sophisticated program like SDRandel.
----

'''Main components''' : SDRangel, Ollama, Node-Red, UI Dashboard.
'''Installed on''' Windows laptop with WSL Ubuntu flavor.

Content :

Hoofdpagina

2025-08-25T18:36:43Z

Pe2jko: /* Aantekeningen */

__NOTOC__
'''Dit is de project Wiki van de projectgroep .540'''

Voor de [https://www.qsl.net/pa0sny/vijfveertigDutch.html homepage van de .540 klik hier].

[[Huisfrequenties]]

== Activiteiten ==
Om op de hoogte te blijven van de activiteiten van de projectgroep 540, aboneer u dan op de nieuws emaillijst.
Voor instructies zie: [[E-mail]]

== Projecten ==
* [[Universele Zender Project]]
* [[Nokia Repeater]]
* [[Lima SDR]]
* [[Offset parabool antenne met patch straler voor 13 cm (WiFi) ]]
* [[Stralers voor 23 cm, 13 cm en 3 cm voor in parabool ]]
* [[Opzet DVB-S Print voor Raspberry PI ]]

* [[SETUP-DATV DVB-S Print for Raspberry PI in the English language ]]

* [[Grafische interface voor LEANDVB ]]

* [[DVB-S zender met 1x Raspberry PI3 en RPIDATV ]]

* [[ Experimenten met parabool antenne's voor ontvangst 10 GHz (D)ATV ]]

* [[ The PG540 Spotnik Network ]]

* [[ LoRa APRS Tracker and I-Gate ]]

== Aantekeningen ==
* [[Quangcheng UV-K5, UV-K6]]
* [[USBTV ruis op monitor]]
* [[LNB overzicht]]
* [[Huisfrequenties]]
* [[FPGA development kits]]
* [[Digilite-ZL]]
* [[Digilite-Raspberry Pi 2x2]]
* [[Software defined radio]]
* [[PLL LNB]]
* [[HackRF notities]]
* [[USRP B200]]
* [[DVB-S]]
* [[DVB-S2]]
* [[DVB-S USB ontvanger Hauppage DEC3000]]
* [[GnuRadio]]
* [[Digitale ingang]]
* [http://www.webcamsue.nl/atv/ Digitale (D)ATV streams NL en WWW Global * tip!]
* [[LimeSDR interface to SVXlink using GNUradio]]
* [[DVB-T 2 Mhz Ham-Mode instellingen op PI6ZDM]]
* [[DVB-S 2KS DATV-Express instellingen op PI6HLM]]
* [[Yaesu FT-2311 23cm FM]]
* [[RPITX interface to SVXlink using GNUradio]]
* [[ADALM-PLUTO (SDR rx/tx) notes]]
* [[Eshail 2 ontvangen met een LNB en de RTL-SDR]]
* [http://www.pabr.org/radio/lnblineup/lnblineup.en.html#lo Uitgebreide PLL LNB Informatie * tip! ]
* [https://uhf-satcom.com/blog/patch_antenna Zelfbouw Es'hail-2 Oscar 100 Dual Band Patch Antenna]
* Homemade polarmount by HB9CVG, het PDF document: [[media:20190508_Polar_Mount.pdf]]
* [[Nano VNA user guide]]
* [[Adalm Pluto en Debian linux]]
* [[Adaptive power control using MQTT (DATV on QO-100)]]
* [[Rocket Combi Antenna QO-100]]
* [[100W LED lamp]]
* [[Portsdown4 Node-red interface]]
* [[10GHz eenvoudig qrv met een HB100]]
* [[LongMynd to Nextion Interface]]
* [[Nokia RD40]]
* [[RFE for PlutoDVB2]]
* [[SDRAngel driven by Ollama LLM using MCP]]

== Andere sites van de 540 groep ==
* [https://www.qsl.net/pa0sny/vijfveertigDutch.html Homepage]

== Archief ==
* [[Dag voor de Radio Amateur (DvdRA) 2014]]

== Hulp ==

Raadpleeg de [//meta.wikimedia.org/wiki/NL_Help:Inhoudsopgave handleiding] voor informatie over het gebruik van de wikisoftware.

LongMynd to Nextion Interface

2025-04-03T19:33:39Z

Pe2jko:

Longmynd to Nextion Interface

'''Info @''' joopk@hccnet.nl

'''What is LongMynd @''' [https://wiki.batc.org.uk/LongMynd_Receive_Software LongMynd BATC information]

Receiving part of my QO-100 station is build around Longmynd on PI4 close to my dish. Frequency/Symbolrate selection is done via [https://github.com/m0dts/QO-100-WB-Live-Tune QO-100-WB-Live-Tune from M0DTS] and works fantastic. My experiment was trying to use HMI interface touch screen (Nextion 7 inch) controlling my complete QO-100 station incl the Longmynd tuner. Following flowchart (hardware) is used (only RX is explained here) :

[[Bestand:Flow-nextion-quicktune.png]]

I choose the resolution of my interface maximum 14 channels. In each channel only 1Ms/s, 500Ks/s,333Ks/s can be detected. QO-100 WB Quicktune in Winterhill mode will scan the band each 2seconds and output via ethernet frequency and Symbolrate (on port 9900). This information is captured by the RPI-4 connected to the Nextion HMI display. It is being handled by Node-Red to make the decision what image to display on the Nextion. If the frequency is within specific window I determine what channel the station is received. If channel is for example 10, then I take into consideration the Symbolrate, if 333 Ks/s I display small green square, if 500Ks/s I use another picture with green wider bard, if 1 Ms/s even wider green bar. Each 8 seconds I clear all images on screen and recalculate what Quicktune is telling me. When I would like to see the station I touch the green bar and on the Nextion, a red indicator is drawn to let me know which channel is currently selected. Then I send command to Longmynd to tune to that frequency with that Symbolrate. The output ( video ) is captured in VLC or SMplayer on my PC. Due to the fact that I wrote also an MQTT interface publishing all information from Longmynd received station , I can easily show that on the Nextion display, showing MER/D value, Station name and FEC. Due to the fact that I also installed Node-red on my PC I am able to start/stop SMplayer in order to stop/start showing the stream (video). 3x Node-red, 1x Mosquitto and 1PC and 2 RPI-4 are working together.
Sending commands to Nextion from Node-red is made out of 2 blocks, a function convert payload to ascii values and adding 3x code 255 :

<pre>
var str = msg.payload;
var buf = []
for (var i=0, l = str.length; i < l; i++) {
var ascii =str.charCodeAt(i);
buf.push(ascii);
}
buf.push(255);
buf.push(255);
buf.push(255);
msg.payload = new Buffer(buf);
return msg;
</pre>

[[Bestand:Nextion-function-tx.png]]

Thats is feed into a serial out node. For receiving values from Nextion also a Serial node is used, but then a serial in node. This is first send to a switch which will detect which ID is touched on the Nextion. Each element will get a unique ID and send to Node-red. The switch will determine where this ID is needed. For example if the first channel is touched then it will go the a function "touch channel 1" :

<pre>
code=parseInt(waarde,16)
if (code == 301) {
tune="[GlobalMsg],Freq=10492750,Offset=9750000,Doppler=0,Srate=333,WideScan=0,LowSR=0,DVBmode=Auto,FPlug=A,Voltage=0,22kHz=Of"
}
if (code == 501) {
tune="[GlobalMsg],Freq=10492750,Offset=9750000,Doppler=0,Srate=500,WideScan=0,LowSR=0,DVBmode=Auto,FPlug=A,Voltage=0,22kHz=Of"
}
if (code == 1001) {
tune="[GlobalMsg],Freq=10492750,Offset=9750000,Doppler=0,Srate=1000,WideScan=0,LowSR=0,DVBmode=Auto,FPlug=A,Voltage=0,22kHz=Of"
}
msg.payload=tune
return msg
</pre>
In Nextion UI I define that when channel 1 is touched, code 301/501/1001 is send. In the same time QuickTune will tell Node-red if it is a 333/500/1000 Ks/s station on channel 1. I disable touch function for graphic element which is not the correct value. So if it is a 333ks/s station I disable the graphic element for 500ks and also the one for 1000 Ks. So when I touch channel 1, only element 333ks/s is visible and Nextion will send value 301 to my RX receive node, the function will create the string for Longmynd to tune to that frequency with that samplerate. If a station of 500ks appear on channel 5 for example, I make the 333ks and 1000ks/s inactive, and only the 500ks/s become visible. If I touch it, Nextion will send 505, the vaulie is then intepreted by the function as 500ks/s station on channel 5. It creates the string which is send over ethernet to Longmynd. This now works on all 14 channels.

[[Bestand:Nextion-switch-flow.png]]

The Focus blocks will move a small red square indicating what channel is touched. This is handy so I can see which channel is selected. It will only move a smal red square in horizontal axis.

[[Bestand:Port9900-nextion.png]]

Above Node-red blocks listen to Quicktune port 9900 and will split each message to the correct Symbolrate and frequency. These blocks take care that the correct image is displayed on nextion. As I mentioned there are 3 different size green blocks, the 333ks is the smallest, the 1000ks/ the biggest. So visually it can be seen quite quickly if it is 333/500/1000ks. It is also take that the green block is shown on the right channel. This in general the functioning of this experiment.
Nextion design UI interface with all graphic elements activated (here are also the control for the Pluto and powerstages and portsdown4, but not explaned in this document) :

[[Bestand:Nextion-design-complete.png]]

Nextion interface after boot. I disable all TX settings because by default the transmitter is OFF. Below you see the graphic elements showing channels which are occupied, on the first 9 channels there can be 3 different Symbolrate stations, therefore 3 graphic elements with different width are on top of eachother, I make them visible or hide them whatever s currently active. If station of 1000KS. transmit on channel 5 then I disable the 333ks on channel 4 and 6, and disable the 500ks element on channel 4 and 6, then make element 1000ks/s visible on channel 5, if I tocuh it then Longmyd will get the command to go there and show the stream.

[[Bestand:Nextion-rx-only.png]]

Experiment succeeded. Lessons : element ID by Nextion UI design software is changing whenever you add elements/switches/text/and so on. The nodes in Node-red are relying on the correct ID, so it happened few times that I had to define the correct ID to the correct Switch node. The ID numbers are generated from top left to top bottem and each element will get is't number automatically. Giving names to each element makes it easier to read what it is doing. Designing graphic elements was something new and I think that in other projects perhaps I will use Boxy SVG, looks quite powerfull. The experiment was fun, and again show that Node-Red/MQtt is super powerfull and handy for Ham radio use.

'''Info @''' joopk@hccnet.nl

RFE for PlutoDVB2

2025-03-17T19:38:21Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' joopk@hccnet.nl

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

'''Update''' : Michel de HB9DUG added a flow which links to the Receiver flow. The original receive frequency was selectable only with dropdown menu. This is not so flexible, Michel took the output of our [https://github.com/m0dts/QO-100-WB-Live-Tune QuickTune tool] and linked it to the Frequency and Samplerate input. So if you click on a station in Quicktune, the tuner will move freq and set correct Samplerate. Thanks Michel. Please see below the flow from Michel.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]

QuickTune interface flow chart from Michel HB9DUG which links to freq input and samplerate input controlling the DATV Tuner connected to Pluto.

[[File:Hb9dug-ext.jpg]]

LongMynd to Nextion Interface

2025-03-17T19:37:48Z

Pe2jko:

Adaptive power control using MQTT (DATV on QO-100)

2025-03-17T19:37:15Z

Pe2jko:

'''Automatic Adaptive power settings for DATV on WB Transponder QO-100'''

'''Info @''' joopk@hccnet.nl

'''Credit''' F5OEO, Evariste

'''Hardware Equipment used :'''

1.1m offset dish

[https://wiki.batc.org.uk/MiniTiouner_hardware_Version_2 Tutioune V.2 tuner BATC]

Raspberry PI4

Pluto + Amplifier

'''Software used :'''

Longmynd DATV receiver software [https://github.com/myorangedragon/longmynd ( Source on GitHub )]

Node-Red [https://nodered.org/docs/getting-started/windows Starting point install Node-Red on PC)]

F5OEO firmware v.0303 ( still in beta, March 2021 )

UDP message conversion LongMynd to MQTT ( source available , please send mail )

'''Advantages : '''

1) When crowded Transponder DATV station remains with constant powerlevel, easy for other receiving stations to have signal @ minimum Snr level.

2) With changing weather conditions power level is adjusted acordingly, rain/snow have no influence for receiving stations.

3) Automatic power level when changing fec or samplerate.

4) Effective use of Transponder.

'''Method of Operation :'''

System is using MQTT messaging to receive Snr values from LongMynd receiver and sending messages to modulator setting powerlevels. This setup create a locked loop and when defining the correct levels system is automatic and stays between defined levels.
When swiching on the DATV modulator , LongMynd receiver must be tuned to same frequency and setup with the correct SampleRate. ( Currently it is manual, but plan is to make this also automatic ).
When tuned the LongMynd will detect a lock and start sending MQTT messages to central broker (in my case running on a Raspebrry PI3). Node-red ( in my case on PC ) subscribe to this topic. Settings of Modulation code and Fec determine the minimum Snr.
This value + 1 dB is set as min_snr value. Max_snr value is 1 dB higher then min_snr. This will give a 1dB window and minimum D1 on receiver. Then when receiving Snr drops below the min_snr the modulator
will be told to step up it's power. Once it reaches the min_snr it stops increasing power. When receiving Snr is above snr_max then modulator will reduce it's power output. System is dynamic so when other samplerate
or fec is choosen the system calculate min_snr and max_snr and modulator start to adjust to find the correct power leven to be just above the min_snr value. Same time dus to changed Fec/Samplerate
the transport stream has to be stopped and calculated and started again. The modulator add null packets during that process and modulator continue to output.
To prevent overshoot or undershoot of powerlevel message limit was introduced to 1 message per 2 seconds. So power adjustments are slow. Dynamic power can be switched on/off using Gate node.

LongMynd currently is not supporting MQTT messages, therefore an convertor was made between the standard UDP messaging build into LongMynd and MQTT. Information from LongMynd is converted to MQTT
using the opensource [https://github.com/LiamBindle/MQTT-C MQTT-C implementation ]. This program runs on Raspebrry PI4 together with LongMynd software.

Modulator from F5OEO starting with Firmware 0303 supports MQTT messaging and Node-Red on PC subscribe to topics on the local MQTT broker on Pluto device and also publish messages on the local Pluto MQTT broker.
For example to set the power level. The flexible Node-Red will make all the connections and build the GUI around this solution.

Please see some Node-Red examples :

'''Full Dashboard March 2021'''

[[Bestand:Mqtt-pluto-dashboard.PNG|900px]]

''' Global settings for FFMPEG ''' :

These 3 parameters are captured in order to pass to a batch file which tell FFMPEG what to do. Resolution, Frames per second and Mode. The batch file will select the correct input sources depending on this setting. The output of these nodes are going to other tab where the paramaters are send to the batch file. I write the settings to a local file, so when the system starts up it will remember what was the last settings. Each time you change the global setting the file linked will be overwritten with the new setting.

[[Bestand:Mqtt-global-ffmpeg.PNG|700px]]

'''Pluto MQTT Status flow'''

Pluto have it's own MQTT broker inside which will plublish messages. In this flow I connect to Pluto mqtt broker and sunscribe to few topics. There are many topics, this is for me the most important ones. MQTT.fx client can help you finding out which topics are availbel, becuase there is a scan feature inside. The full list is not yet available. But from the flow you can see the ones I use. Just use a nice GUI widget to show the content.

[[Bestand:Mqtt-pluto-status.PNG]]

'''Adaptive Power control flow'''

It starts with subscribe to the MER topic ( the LongMynd tuner will send messages about its received value when locked ). This will be send into a GATE node, this node will block or allow payload to travel through the gate. A function will compare the MER value to min_snr and max_snr. If it is between these threshold it will send "OK" , when it is too low it will send "UP", when it is too high it will send a "DOWN" message. Then I added a limit Node to limit the amount of messages to 1 message each 2 seconds. This message will be send to second funciton node who will drive the power of the Pluto. As the power window is from -60 to 0 I am counting up or down with steps of 1. SO if I receive message UP then I increase ( more closer to 0 ) the value, when I receive a DOWN message I will reduce power by decrease the value. I set the absolute minimum and maximum values to -18, becuase I don't want to burn my AMP. So the counting down will stop at -18. That is the highest possible value I send to Pluto power. In addition the LongMynd receiver must be tuned to the frequency and the samplerate of the transmitter, otherwise it can't lock. Once we go "on air" then UDP message with frequency and smaplerate values ( similar to the QuickTune appiication ) are being send to Raspberry PI4 with Longmynd. It will tune automatically. So now both receiver and transmiter are in sync.

'''Function what to do of MER is lower or higher then threshold:'''
<pre>
var mer = msg.payload
var pwr
var min = flow.get("min_db");
var max = flow.get("max_db");
var mm = parseFloat(mer).toFixed(2);
if (mm >= min) {
if (mm <= max) {
msg.topic = "OK"
} else {
msg.topic = "DOWN"
}
} else {
msg.topic = "UP"
}

return msg;
</pre>

'''Function to in/decrease power level depending on status (UP/DOWN/OK):'''

<pre>
var count = flow.get("count")||-40;

if (msg.topic === "init") {
count = msg.payload;

} else if ((msg.topic === "UP") && (count< -18)) {
count++;
} else if ((msg.topic === "DOWN") && (count > -60)) {
count--;
} else if ((msg.topic === "OK") ) {

}
// Save the new value back to context so it will be available next time
flow.set('count',count);
// Update the message payload and return - no need to create a new msg
msg.payload = count;
return msg;
</pre>

'''Scary complete flow, don't be afraid'''

This is the full flow controlling some more devices, as I also can switch on/off my pre-amp and final amp. Called "trap1/2/3". Please see the incoming MQTT nodes, the functions and UI output widgets. Also the nodes are included to define the min_snr and max_snr values. I write 2 files in a directory which contains the value of FEC and Modulation Code ( QPSK/8PSK etc ), these 2 parameters define the miniumum Snr required to receive the signal. For example QPSK Fec 1/2 needs 1 dB above the noise. A batch file input = fec and modcode, output is Snr value. This Snr value I read into the flow and add 1dB for min_snr and +2 dB for max_snr values. This in theory will bring the receiver on D1 receive level. ( Snr - min required Snr = D value ). So in the flow the min_snr and max_snr is feed into the Function to define UP/DOWN/OK messages. So this is all dynamic, means that if I change the FEC or Modulation Code automatically the Pluto will adapt to this min_snr and max_snr values by increasing or decreasing the Pluto Power levels. ( min = -60, max = 0 )

[[Bestand:Mqtt-control-flow.PNG|900px]]

'''Connections to manually set parameters in Pluto using MQTT :'''

In this flow I am able to set other parameters in Pluto using MQTT publish messages. Also the connections are visible to write the snr_min and snr_max values and the process to stop/start ffmpeg. This is required becuase when dynamically change the fec/samplerate first FFMPEG needs to be killed , then the new minimum samplerate ( calculated by the Pluto ) needs to be given as muxrate. If you don't do it, then video/audio will be intermittant. As with this new firmmware from F5OEO we can change it on the fly without stopping and starting the the transmissing. F5OEO add null packets when input stream is missing.

[[Bestand:Mqtt_settings.PNG|800px]]

'''Conclusion''':

Although very nice feature works nice. Beatifull to see it work when transponder is busy and strong signal arrive and disappear. The output power of Pluto changes with small steps. This setup require some experience with Node-Red, but there is so much information on internet how to build flows and how to create functions that it is not too difficult. Question ? pe2jko@pg540.org

'73

RPITX interface to SVXlink using GNUradio

2025-03-17T19:36:27Z

Pe2jko:

'''Interface RPITX to SVXlink.'''
[[Bestand:Rpitx-plaatje.jpg | thumb ]]
Inspired from the setup of the Spotnik made by [https://f5nlg.wordpress.com/2016/01/06/svx-boutique/ F5NLG] and the Reflector technique from [https://github.com/sm0svx/svxlink/wiki SVXlink] and the French reflector network hereby the description of the experimental interface between [https://github.com/F5OEO/rpitx/tree/v2beta RPITX from F5OEO] and SVXlink using GNUradio. The GNUradio flowchart was made with examples [https://github.com/ha7ilm/rpitx-app-note from these application notes] . SVXlink have UDP input and output possibilities and these are used to input/output to GNUradio blocks. Setup I use is RX on 433.540 Mhz and TX is on 438.775 Mhz. I use a Wouxun transceiver ( dual band ) to communicate. TX is set to 433.540 and receive is set to 438.775 in the 70cm amateur band.

'''Picture test setup show green case contain 7inch touch screen, inside the blue case is Raspberry PI3 B+, extension cable to RTL dongle and small brown cable connected to PIN7 as transmit antenna'''

'''Equipment used''' : As SBC I use the [https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/ RPI model 3B+] (with Rasbian Stretch) and as receiver I use the [https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/ RTL dongle V3 from RTL-SDR.com] No other hardware is required.

'''Functional Description''' : The receiver side is all handled by allready existing functionality in SVXLink using Ddr receiver. All configuration is well documented in [http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html svxlink.conf]. The transmitter part interface is made out of 3 components. The audio coming from SVXlink TX1 is routed via UDP port 1235 to GNUradio, the PTT is routed to PseudoTTY port /home/pi/ptt and the TCP output port 8011 of GNUradio IQ stream is routed to RPITX. When SVXlink wants to transmit it sends a charackter T to the PseudoTTY device ( PTT ON ), a perl script which is started after the start of SVXlink will monitor this PseudoTTY and once it will see the character T it will execute other script starting first RPITX snd then Python GNUradio script. This will switch on the transmitter and audio is routed to RPITX. When SVXlink need to stop transmitting then the character R is send by SVXlink to the PseudoTTY and received by the script monitoring the PTY. It will kill RPITX and Python GNUradio script. As it takes a bit of time to start RPITX ( initializing the PLL ) and starting the TCP listener and starting Python some extra delay is given to SVXLink in the configuration.

'''Questions ?:''' please mail to joopk@hccnet.nl

'''Scripts and schematic GNUradio flowchart :'''

[[Bestand:Rpitx_grc.JPG]]

----

''' Perl Script which listen on the PTY port from TX1'''

<pre>

#!/usr/bin/perl
#
# @file nhrcx.pl
# @brief Perl-script to link a NHRCx controller to SvxLink over
# Linux pseudo tty's
# @author Adi Bier / DL1HRC
# @date 2014-05-01
#
# Run this script after starting SvxLink. Do not configure the
# links in the /dev directory.
#
# SvxLink - A Multi Purpose Voice Services System for Ham Radio Use
# Copyright (C) 2004-2014 Tobias Blomberg / SM0SVX
# Adjusted PE2JKO to control RPITX

use Time::HiRes qw(usleep);
#use Device::SerialPort;
use IO::File;

$ptt_port = "/home/pi/ptt";
$logfile = "/tmp/nhrc-x.log";
$DEBUG = 1;

$PTT = openPtty("$ptt_port"); # ptt port from SvxLink

while (1) {

$PTT->read($p, 1);
if ($p gt ' ') {
$message = $p;
if ($p ne 'T') {
system("/home/pi/rpitx/stop_tx.sh");
&writelog("UIT");
}

if ($p ne 'R') {
system("/home/pi/rpitx/start_tx.sh");
&writelog("AAN");
}

&writelog("PTT-command: $p");
undef $p;
}

usleep(10000);
}
close($PTT);
exit;

sub openPtty {
my $fh = IO::File->new($_[0], O_NONBLOCK|O_RDWR);
if (!(defined $fh)) {
&writelog("Can not open $_[0]");
print "Can not open $_[0]\n";
return 0;
}
$fh->autoflush(1);
&writelog("opening $_[0] OK");
return $fh;
}

sub writelog {
if ($DEBUG) {
open(LOG,">>$logfile");
print LOG $_[0],"\n";
close(LOG);
}
}

</pre>

'''The startup script starts first svxlink, this opens the PTY port and then the perl script which monitor the charakters (T and R)'''

<pre>

#!/bin/sh

echo "start"
/home/pi/reflector/src/build/bin/svxlink &
sleep 1
/home/pi/ptt.pl &
exit

</pre>

'''Script start_tx.sh will be called when ptt.pl detect that PTT should be switched on'''

<pre>

#!/bin/sh

echo test
nc -l 8011 | sudo /home/pi/rpitx/rpitx -i- -m IQFLOAT -f 438775 &
python /home/pi/rpitx_interface.py &
exit

</pre>

'''Stop_tx.sh script called when SVXlink want to stop sending, so I kill processes'''

<pre>

#!/bin/sh

echo "stop"
sudo killall nc python rpitx
exit 0

</pre>

'''SVXlink configuration changes are :'''

In [RX1] of svxlink.conf configure TYPE=Ddr, SIGLEV_DET=DDR, SIGLEV_DET=2.61, SIGLEV_OFFSET=150, FQ=433540000, WBRX=WbRX1

In [WbRX1] put TYPE=RtlUSB, DEV_MATCH=0, HOST=localhost, PORT=1234, CENTER_FQ=433540000, GAIN=3.7,PEAK_METER=1, SAMPLE_RATE=960000

In [TX1] put TYPE=LOCAL, AUDIO_DEV=udp:127.0.0.1:1235, AUDO_CHANNEL=0, PTT_TYPE=PTY, PTT_PTY=/home/pi/ptt

These are the most important and relevant settings which need to be set.

DVB-S 2KS DATV-Express instellingen op PI6HLM

2025-03-17T19:35:55Z

Pe2jko:

'''Instellingen DVB-S voor PI6HLM.'''
[[Bestand:DATV-Express.JPG | thumb ]]
'''Datum December 2018'''

PI6HLM ATV repeater heeft diverse digitale ingangen, o.a. een DVB-S ingang op 1252.6 Mhz en 436 Mhz. De gebruikte DVB ontvanger is een Tandberg ontvanger. Deze ontvanger is vast ingesteld op 200Ks/S, Fec 1/2, Service ID 1. Op deze Wiki pagina vind je de instellingen voor een specifieke DVB-S opstelling van een [https://www.crowdsupply.com/lime-micro/limesdr-mini LimeSDR mini] en [https://www.datv-express.com/ DATV-Express software]. Hoofdzakelijk kun je hier de instellingen van DATV-Express terugvinden. Voor vragen e-mail naar joopk@hccnet.nl

----

[[Bestand:DATV-Express.JPG]]

----

[[Bestand:video_capture_settings.JPG]]

----

[[Bestand:video_codec_settings.JPG]]

----

[[Bestand:audio_capture_settings.JPG]]

----

[[Bestand:audio_codec_settings.JPG]]

----

[[Bestand:Output_format.JPG]]

----

[[Bestand:SI_Table_Settings.JPG]]

----

[[Bestand:Express_settings.JPG]]

----

[[Bestand:DVB-S_settings.JPG]]

----

LimeSDR interface to SVXlink using GNUradio

2025-03-17T19:35:18Z

Pe2jko:

'''Interface SVXlink to LimeSDR.'''
[[Bestand:20180426_084801_resized.jpg | thumb ]]
Inspired from the setup of the Spotnik made by [https://f5nlg.wordpress.com/2016/01/06/svx-boutique/ F5NLG] and the Reflector technique from [https://github.com/sm0svx/svxlink/wiki SVXlink] and the French reflector network hereby the description of the experimental interface between SVXlink and [https://www.crowdsupply.com/lime-micro/limesdr-mini LimeSDR tranceiver] using GNUradio. The GNUradio flowchart was made with examples from OZ9AEC (NBFM TX/RX) and Michael DK5HH. SVXlink have UDP input and output possibilities and these are used to input/output to GNUradio blocks. The LimeSDR used in my setup is the LimeSDR mini (only 1 TX and 1 RX channel). Setup I use is RX on 430.540 Mhz and TX is on 438.775 Mhz. I use a Wouxun transceiver ( dual band ) to communicate. TX is set to 430.540 and receive is set to 438.775. (Simplex frequencies also possible)

----

SVXlink TX audio is send to UDP Source and modulated in NBFM to the Osmocom block for the LimeSDR and audio is transmitted on 438.775.

SVXlink RX audio is feed from UDP sink received from the Osmocom receiver block on 430.540 Mhz and converted with NBFM receiver.

----

SVXLink.conf RX1 can be setup as AUDIO_DEV=udp:127.0.0.1:1234

SVXLink.conf TX1 can be setup as AUDIO_DEV=udp:127.0.0.1:1235

SVXlink audio interface op 16Khz

----

GNUradio block parameters are adjusted for this specific setup and are depending on antenne setup/distance from Portofoon and LimeSDR. These paramaters most likely need adjustments. Computer used with this setup is [https://www.udoo.org/udoo-x86/ UDOO X86 Advanced Plus] (50% CPU load) with Ubuntu 16 using GNUradio 3.7.12.

'''Update''' now setup is used with Raspberry PI 2. See thumbnail picture how it looks like.

Information how to build and use latest released SDR stack from source : [http://blog.reds.ch/?p=43 Building a full SDR stack from source for LimeSDR]

----

[[File:Screenshot_from_2018-03-17_20-47-40.png]]

----

[[File:Screenshot_from_2018-03-17_20-46-56.png]]

----

Any questions mail to joopk@hccnet.nl

DVB-T 2 Mhz Ham-Mode instellingen op PI6ZDM

2025-03-17T19:34:25Z

Pe2jko:

'''Instellingen DVB-T voor PI6ZDM.'''
[[Bestand:hides.png | thumb ]]
'''Datum October 2018'''

PI6ZDM ATV repeater heeft diverse digitale ingangen, o.a. een DVB-T ingang op 1265 Mhz. De gebruikte DVB ontvanger is een [http://www.hides.com.tw/product_HV120_eng.html Hides ontvanger]. Deze ontvanger kent diverse modes waaronder de zogenaamde HAM modes, welke buiten de commerciele toepassingen vallen. Daarmee kan de bandbreedte instellingen gewijzigd worden, Normaliter zijn 6,7,8 Mhz bandbreedte gebruikelijk, deze ontvanger ondersteund ook 2,3,4 en 5 Mhz. Op deze Wiki pagina vind je de instellingen voor een specifieke DVB-T opstelling van een [https://www.crowdsupply.com/lime-micro/limesdr-mini LimeSDR mini] en [https://www.datv-express.com/ DATV-Express software]. Hoofdzakelijk kun je hier de instellingen van DATV-Express terugvinden. Voor vragen e-mail naar joopk@hccnet.nl

----

[[Bestand:video_capture.JPG]]

----

[[Bestand:video-codec.JPG]]

----

[[Bestand:audio_capture.JPG]]

----

[[Bestand:audio-codec.JPG]]

----

[[Bestand:output_format.JPG]]

----

[[Bestand:si_tables.JPG]]

----

[[Bestand:express_seetings.JPG]]

----

[[Bestand:DVB-T_settings.JPG]]

----

Grafische interface voor LEANDVB

2025-03-17T19:33:25Z

Pe2jko:

'''Grafische Interface voor LEANSDR V5.0'''

[Originele link naar LEANSDR http://www.pabr.org/radio/leandvb/leandvb.en.html]
----

[[Bestand:Lean18_compl.png]] Schermafbeelding Python Script

----
'''Update September 2019:''' DVBS2 added to the User-interface. LEANDVB capability to decode DVBS-2 was added and therefore the necessary changes were implemented in this latest Wrapper for LeanDVB. This python script is depending on the leandvb software which needs to be compiled first. Once succesfully compiled this script can be copied in your home directory. Also copy "logo.png" [[Media:Logo_lean.png]] (please rename the logo_lean to logon.png) and lean_stop script in your home directory. Functional description, you can start the script by typing "python lean18.py" ( without the quotes ). The script will setup default paramaters suitable for DVBS2. In the same command shell the program and also Leandvb writes messages, in case of start up problems please read the messages. First thin is to goto settings and please fill in the path where the script can find leansdr and ldcp_tool. As a start you can keep the defaults. Later you can tweak parameters for example the gain or the specific DVBS2 parameters. The purpose of these parameters can be found on the website of Leandvb. Here you find what is Inpipe, RRC reject filters and roll off factors. This script only will pass these settings on when leandvb needs to be started. Python script will write a file in your home directory called "leanlastrun" and is used to keep the configuration when the program was used. What the python script is doing is to read all the settings and create a small shell script with the parameters needed to decode DVBS or DVBS2 and then it is executed. The shell file which is created is called "runlean". It is an open file which you can investigate what parameters is being given to leandvb.
Once leandvb is running and can decode the stream then is it piped to "ffplay". It is a very fast program to show the video. If you click on "stop" then the script will close ffplay and leandvb. Then you have the possibility to select other settings ( for xample another frequency ) and hit start again and so on. Prerequite is LEANDVB with DVBS2 capabilities compiled, then FFPLAY , and Python. In order to show the logo you have to run "sudo apt-get install python-imaging-tk. You can create your own logo to be displayed, just create a png file of approx 180x180 pixels and then copy the file logo.png in your home directory. The Python script is open and can be changed to your own needs. motivation to extend this python script with DVBS-2 was due to the launch of Oscar-100, a radio amateur transponder with WideBand DATV frequency space. This can be received by leandvb and an RTL dongle. Also thanks to Nico (ON7NDR) for his testing and recommendations, he tested directly with stations on Oscar-100. You can copy paste the script below in a file, then name it lean18.py , save it in your home directory. Then type "chmod +x lean18.py" (without the quotes) then you can run it from a command shell by typing ./lean18.py. Or you can type "python lean18.py". PS the name is not important, you can name it what you like. In case you would to receive a zip file with the content please let me know by mail pe2jko@pg540.org and will send you a zip file. Note : In order to install and work with leandvb and this wrapper a reasonable knowledge of Linux is required. Please see below some pictures of succesfull received stations from Eshail-2 Oscar-100. Thanks to Nico !

----
'''Uitgebreide Installatie instructies LEANDVB en LEANDVB Interface van Nico ON7NDR''' Hierbij de zeer uitgebreide installatie instructies inclusief illustraties en schermafbeeldingen. Prachtig stukje werk ! --> [[Media:Deel_1_installeren_van_leandvb_in_ubuntu_18.pdf| Deel 1, Leandvb installatie]] --> [[Media:Deel_2_de_Grafische_Interface.pdf| Deel 2 grafisch interface installatie]]

----
'''Update Oktober 2017:''' Toegevoegd LimeSDR frontend. Keuze nu uit RTL-SDR of LimeSDR input. Dankzij de aanpassing van de maker van LEANSDR om 16 bit int´s te ondersteunen maakt het mogelijk om ook andere SDR radios te gebruiken. In combinatie met voorbeeldsource van LimeSuite ( BasicRX.cpp ) was het makkelijk om de LimeSDR te gebruiken als front-end. Ik heb in de settings nu een keuze mogelijkheid of je met de RTL of de Lime wilt ontvangen, als je de lime kiest kun je antenne input, bandbreedte en gain instellen. De IQ samples worden naar een pipe geschreven en Leandvb neemt die pipe als input data. Source beschikbaar als je ermee wilt werken. Testen met hoge samplerates zijn nog niet gedaan, alle sample rates van 2000 KS/s tot aan 150 Ks/s werken prima. Op deze manier wordt het mogelijk om op 13cm en 9cm ook DATV te ontvangen.

'''Motivatie:''' LEANDVB is eigenlijk geschreven om de ISS te volgen en een DVB-S opname te maken zodra hij binnen bereik komt met behulp van een RTL SDR dongle. Software wordt aangestuurd door parameters op de command line. Om eenvoudiger het programma te kunnen gebruiken heb ik er een Python script omheen gemaakt waardoor de meest gebruikte parameters ingesteld kunnen worden in daarvoor gemaakte invoer velden. Ik zal het hier beschrijven en delen op deze pagina. Een aantal parameters zijn belangrijk, de ontvangst frequentie, de sample rate en de afwijking van de RTL dongel. (Erg belangrijk bij lage sample rates). Voor deze parameters zijn 3 aparte invoervelden gemaakt, daarnaast kun je opgeven of je de automatische gain aan wilt zetten en of je low sample rate gaat gebruiken, bv 250 KS/s. Script berekend de sample rate die de RTL dongel mag gebruiken. Uiteindelijk maakt dit programma een opstart bestand genaamd ¨runlean¨ en gaat dit opstarten als op button ¨execute¨ klikt. De ingestelde parameters worden ook opgeslagen in een bestand genaamd ¨leanlastrun¨, dit bestand wordt ingelezen als je het programma weer opstart, anders zou je telkens weer de parameters moeten ingeven en dat vinden wij niet zo leuk. Dit script start ook meteen leandvb op, dus je krijgt meteen wat te zien als je op ëxecute¨ klikt. Om een andere instelling te activeren moet je eerst leandvb en eventueel een schermafbeelding sluiten ( kruisje sluiten activeren in 1 van de leandvb windows). PS, als je geen ffplay hebt dan kun je dit vervangen door mplayer in het script.

'''Installatie tips:''' Zie hieronder de source, als je dit copy-paste in een bestand en in dezelfde directory zet als leandv en je geeft het bv de naam ¨leandv-gui.py¨ dan kun je dat bestand een vlag geven dat het opgestart kan worden als je er dubbel op klikt, commando = sudo chmod +x leandvb-gui.py , een andere mogelijkheid om het op te starten is het volgende commando : sudo python leandvb-gui.py . Als je een kleine jpg image van 180x180 pixels genaamd logo.jpg in dezelfde directory zet krijg je een mooi plaatje in de rechter bovenhoek. Als je het er niet inzet blijft die plek leeg.

Ontwikkeld voor Raspberry PI3 (rasbian) en UBUNTU 14.04 of hoger, kan zijn dat bepaalde modules nodig zijn, die kunnen over het algemeen dmv de bekende sudo apt-get commandoś geinstalleerd worden. In ieder geval is sudo apt-get install python-imaging-tk package noodzakelijk dit is om het logo zichtbaar te maken wat overigens zelf te bepalen is, kun je bv je call in zetten (hi)). Voor deze geweldige Software only DVB ontvanger is enige kennis van Linux noodzakelijk. Voordeel is dat je alles kunt aanpassen naar je eigen idee en smaak.

'''Testen:''' 2000 KS/s op Raspberry PI 3 is haalbaar in geval je hem op no-preprocessing zet. F4DAV heeft heel veel verbeteringen aangebracht en instelmogelijkheden. Dit geeft flexibiliteit en inzetmogelijkhden op diverse hardware platvormen. Computer systemen met veel rekenpower kunnen de functie Max Sensitivity gebruiken, Raspberry PI kun je zonder pre-processing of GUI nog een hoge sample rate zichtbaar maken. Zeer flexibel en afhankelijk van ontvangst signaal nivo en kwaliteit kun je een zo optimale instelling kiezen. Als je vragen hebt over de grafische schil, stuur een mail naar joopk@hccnet.nl en probeer je te helpen. Voor deze software is goede kennis van Linux noodzakelijk om op te zetten.

<pre>
#!/usr/bin/env python

from Tkinter import *
from PIL import ImageTk, Image
from os.path import expanduser
home = expanduser("~")
import os

# Simple UI voor LEANDVB, DVBS receiver.
# requires sudo apt-get install python-imaging-tk package
# keep everything in your home directory
# if you add a 180x180 pixels file called logo.png it will be
# showed in richt corner.
# Leandvb by F4DAV (github leansdr)
# Wrapper by pe2jko@540.org

master = Tk()
master.title('LeanDVB DVBS + DVBS2 interface')

parameters = ""
lengte=0
parameter1_conv1=0
parameter2_conv2=0
parameter3_conv3= ""
print "Home directory = " + home
if os.path.isfile(home+"/leanlastrun"):
file = open(home+"/leanlastrun", "r")
parameter1 = file.readline() #freq
parameter2 = file.readline() #samplerate
parameter3 = file.readline() #fec
parameter6 = file.readline() #tune
parameter4 = file.readline() #fastlock
parameter5 = file.readline() #lowsr
parameter7 = file.readline() #viterbi
parameter8 = file.readline() #Gui
parameter9 = file.readline() #dvbs2
parameter10 = file.readline() #max sensitive
parameter11 = file.readline() #hard-metric
parameter12 = file.readline() #rtl0
parameter13 = file.readline() #rtl1
parameter14 = file.readline() #pad leandvb
parameter15 = file.readline() #ppm
parameter16 = file.readline() #ant
parameter17 = file.readline() #gain_lime
parameter18 = file.readline() #gain_lime_bandbreedte
parameter19 = file.readline() #gain_rtl
parameter20 = file.readline() #viewer
parameter21 = file.readline() #rolloff_factor
parameter22 = file.readline() #rrc_rej
parameter23 = file.readline() #nhelpers
parameter24 = file.readline() #inpipe
parameter25 = file.readline()

parameter1_conv1 = str(parameter1[:-1])
parameter2_conv2 = int(parameter2)
parameter3_conv3 = str(parameter3[:3])
parameter4_conv4 = int (parameter6)
parameter16_conv = str(parameter16[:-1])
parameter17_conv = str(parameter17[:-1])
parameter18_conv = str(parameter18[:-1])
parameter19_conv = str(parameter19[:-1])
parameter20_conv = str(parameter20[:-1])
parameter21_conv = str(parameter21[:-1])
parameter22_conv = str(parameter22[:-1])
parameter23_conv = str(parameter23[:-1])
parameter24_conv = str(parameter24[:-1])
file.close()
else:
parameter1_conv1 = 1252
parameter2_conv2 = 2000
parameter3_conv3 = "1/2"
parameter4_conv4 = 0
parameter1 = "1252"
parameter2 = "2000"
parameter3 = 1
parameter4 = 1
parameter5 = 1
parameter6 = 0
parameter7 = 0
parameter8 = 1
parameter9 = 1
parameter10 = 0
parameter11 = 0
parameter12 = 1
parameter13 = 0
parameter14 = home+"/leansdr/src/apps/ "
parameter15 = 1
parameter16_conv = 1
parameter17_conv = "0.5"
parameter18_conv = "3500000"
parameter19_conv = "0"
parameter20_conv = "ffplay"
parameter21_conv = "0.35"
parameter22_conv = "20"
parameter23_conv = "4"
parameter24_conv = "1000000"

var1 = IntVar()
Checkbutton(master, font = "Verdana 13 italic", text="Fastlock", variable=var1).grid(row=5, sticky=W)
var2 = IntVar()
Checkbutton(master, font = "Verdana 13 italic" ,text="Low SR", variable=var2).grid(row=5, column=1, sticky=W)
var3 = IntVar()
Checkbutton(master, font = "Verdana 13 italic" ,text="Viterbi", variable=var3).grid(row=5, column=1, sticky=E)
var4 = IntVar()
#Checkbutton(master, font = "Verdana 13 italic" ,text="Hard-Metric", variable=var4).grid(row=5, column=1)

Label(master,font = "Verdana 10 italic", text="-----------------------").grid(row=4,column=0)
Label(master,font = "Verdana 10 italic", text="---------------------------------------------------------").grid(row=4,column=1)
var5 = IntVar()
Checkbutton(master, font = "Verdana 13 italic", text="Gui", variable=var5).grid(row=7, sticky=W)
var6 = IntVar()
Checkbutton(master, font = "Verdana 13 italic" ,text="DVBS-2", variable=var6).grid(row=7, column=1, sticky=W)
var7 = IntVar()
Checkbutton(master, font = "Verdana 13 italic" ,text="Max sensitive", variable=var7).grid(row=7, column=1, sticky=E)
Label(master,font = "Verdana 8 italic", text="").grid(row=6,column=0)
Label(master,font = "Verdana 8 italic", text="").grid(row=8,column=0)

rtl0 = IntVar()
rtl1 = IntVar()
ppm = IntVar()
padlean = StringVar()
ant = StringVar()
gain_rtl = StringVar()
gain_lime = StringVar()
viewer = StringVar()
rolloff_factor = StringVar()
rrc_rej_factor = StringVar()
nhelpers = StringVar()
inpipe = StringVar()
bandbreedte_lime = StringVar()
var1.set(int(parameter4))
var2.set(int(parameter5))
var3.set(int(parameter7))
var4.set(int(parameter11))
var5.set(int(parameter8))
var6.set(int(parameter9))
var7.set(int(parameter10))
rtl0.set(int(parameter12))
rtl1.set(int(parameter13))
padlean.set(str(parameter14[:-1]))
ppm.set(int(parameter15))
ant.set(parameter16_conv)
gain_lime.set(parameter17_conv)
bandbreedte_lime.set(parameter18_conv)
gain_rtl.set(parameter19_conv)
viewer.set(parameter20_conv)
rolloff_factor.set(parameter21_conv)
rrc_rej_factor.set(parameter22_conv)
nhelpers.set(parameter23_conv)
inpipe.set(parameter24_conv)
e = Entry(master, font = "Verdana 15 bold")
f = Entry(master, font = "Verdana 15 bold")
g = Entry(master, font = "Verdana 15 bold")
h = Entry(master, font = "Verdana 15 bold")
e.insert(0, parameter1_conv1)
f.insert(0, parameter2_conv2)
g.insert(0, parameter3_conv3)
h.insert(0, parameter4_conv4)
e.grid(row=0, column=1)
f.grid(row=1, column=1)
g.grid(row=2, column=1)
h.grid(row=3, column=1)

e.focus_set()
if os.path.isfile(home+"/logo.png"):
im = Image.open(home+'/logo.png')
photo = ImageTk.PhotoImage(im)
label = Label(image=photo)
label.image = photo
label.grid(row=0, column=3, columnspan=2, rowspan=3,sticky=W+E+N+S, padx=5, pady=5)

def einde():
save_parms()
master.destroy()

def preset1():
top = Toplevel()
top.title("Default Settings")
top.geometry("400x400+30+30")
top.transient(master)
# C1 = Checkbutton(top, font = "Verdana 11 italic", text="RTL=0", variable=rtl0)
# C1.pack()
# C2 = Checkbutton(top, font = "Verdana 11 italic", text="LimeSDR=1", variable=rtl1)
# C2.pack()
kk= Label(top, font = "Verdana 10", text="Path to Leansdr :")
kk.pack()
i = Entry(top, font = "Verdana 10", width=35, textvariable=padlean)
i.pack()

# kl= Label(top, font = "Verdana 10", text="------------")
# kl.pack()

kk= Label(top, font = "Verdana 10", text="PPM offset RTL0")
kk.pack()

j = Entry(top, font = "Verdana 10", width=15, textvariable=ppm)
j.pack()

# kn= Label(top, font = "Verdana 10", text="Antenne Lime")
# kn.pack()

# k= Entry(top, font = "Verdana 10", width=15, textvariable=ant)
# k.pack()

# km= Label(top, font = "Verdana 10", text="Gain Lime")
# km.pack()

# l= Entry(top, font = "Verdana 10", width=15, textvariable=gain_lime)
# l.pack()

# lm= Label(top, font = "Verdana 10", text="Bandbreedte Lime")
# lm.pack()

# kp= Entry(top, font = "Verdana 10", width=15, textvariable=bandbreedte_lime)
# kp.pack()

noo= Label(top, font = "Verdana 10", text="Gain RTL (0=Auto)")
noo.pack()

oo= Entry(top, font = "Verdana 10", width=15, textvariable=gain_rtl)
oo.pack()

qoo= Label(top, font = "Verdana 10", text="Roll Off Factor (DVBS2)")
qoo.pack()

qp= Entry(top, font = "Verdana 10", width=15, textvariable=rolloff_factor)
qp.pack()

qooo= Label(top, font = "Verdana 10", text="RRC Rej Factor (DVBS2)")
qooo.pack()

qpp= Entry(top, font = "Verdana 10", width=15, textvariable=rrc_rej_factor)
qpp.pack()

qooop= Label(top, font = "Verdana 10", text="Nhelpers (DVBS2)")
qooop.pack()

qppp= Entry(top, font = "Verdana 10", width=15, textvariable=nhelpers)
qppp.pack()

oooop= Label(top, font = "Verdana 10", width=15, text="Inpipe (DVBS2)")
oooop.pack()

qqppp= Entry(top, font = "Verdana 10",width=15, textvariable=inpipe)
qqppp.pack()

# okl= Label(top, font = "Verdana 10", text="Viewer")
# okl.pack()

# okll= Entry(top, font = "Verdana 10", width=15, textvariable=viewer)
# okll.pack()

kll= Label(top, font = "Verdana 10", text="------------")
kll.pack()
topButton0 = Button(top, bg="yellow", text="SAVE", command = lambda:[save_parms(),top.destroy()])
topButton0.pack()

# topButton = Button(top, text="CLOSE", command = top.destroy)
# topButton.pack(side = BOTTOM )

def save_parms():
sub = ""
samplerate = 0
freq = 0
tune = 0
fastlock = var1.get()
lowsr = var2.get()
viterbi = var3.get()
gui = var5.get()
dvbs2 = var6.get()
maxprocess = var7.get()
hardmetric = var4.get()
rtldongle0 = rtl0.get()
rtldongle1 = rtl1.get()
leanpad = padlean.get()
srsubstring = f.get()
tunesubstring = str(1)
opslaanfreq= e.get()
fsubstring = float(e.get())
tunesubstring = str(1)
freq = fsubstring * 1000000
freqfinal=int(freq)
freq_lime=str(fsubstring)+"M"
samplerate = int(srsubstring) * 1000
fec = tkvar3.get()
tune = h.get()
ppmwaarde = ppm.get()
antennewaarde = ant.get()
gain_rtlwaarde = gain_rtl.get()
gain_limewaarde = gain_lime.get()
viewer_waarde = viewer.get()
rolloff_factorwaarde = rolloff_factor.get()
rrc_rej_factorwaarde = rrc_rej_factor.get()
bandbreedte_limewaarde = bandbreedte_lime.get()
nhelpers_waarde = nhelpers.get()
inpipe_waarde = inpipe.get()
file = open(home+"/runlean", "w")
file.write("#!/bin/sh \n\n")
file.write(sub)
file.close()
file = open(home+"/leanlastrun", "w")
file.write(str(opslaanfreq) + "\n")
file.write(srsubstring + "\n")
file.write(fec + "\n")
file.write(tune + "\n")
file.write(str(fastlock) + "\n")
file.write(str(lowsr) + "\n")
file.write(str(viterbi) + "\n")
file.write(str(gui) + "\n")
file.write(str(dvbs2) + "\n")
file.write(str(maxprocess) + "\n")
file.write(str(hardmetric) + "\n")
file.write(str(rtldongle0) + "\n")
file.write(str(rtldongle1) + "\n")
file.write(str(leanpad) + "\n")
file.write(str(ppmwaarde) + "\n")
file.write(str(antennewaarde) + "\n")
file.write(str(gain_limewaarde) + "\n")
file.write(str(bandbreedte_limewaarde) + "\n")
file.write(str(gain_rtlwaarde) + "\n")
file.write(str(viewer_waarde) + "\n")
file.write(str(rolloff_factorwaarde) + "\n")
file.write(str(rrc_rej_factorwaarde) + "\n")
file.write(str(nhelpers_waarde) + "\n")
file.write(str(inpipe_waarde) + "\n")
file.write(tunesubstring + "\n")
file.close()

def stop():
os.system(home+"/lean_stop")

def callback():
ppmwaarde = ppm.get()
sub = ""
sub1 = ""
view = ""
dvbs2string = ""
samplerate = 0
freq = 0
tune = 0
fastlock = var1.get()
lowsr = var2.get()
viterbi = var3.get()
gui = var5.get()
dvbs2 = var6.get()
maxprocess = var7.get()
hardmetric = var4.get()
rtldongle0 = rtl0.get()
rtldongle1 = rtl1.get()
leanpad = padlean.get()
antennewaarde = ant.get()
gain_limewaarde = gain_lime.get()
gain_rtlwaarde = gain_rtl.get()
viewer_waarde = viewer.get()
rolloff_factorwaarde = rolloff_factor.get()
rrc_rej_factorwaarde = rrc_rej_factor.get()
nhelpers_waarde = nhelpers.get()
inpipe_waarde = inpipe.get()
bandbreedte_limewaarde = bandbreedte_lime.get()
if (viewer_waarde == "ffplay"):
view = "ffplay -v 0"
else:
view = "mplayer"
if (lowsr == 1):
bandbreedte = 1800000
else:
bandbreedte = 2400000
if (fastlock == 1):
fastlockstring = "--fastlock"
else:
fastlockstring = ""
if (viterbi == 1):
viterbistring = "--viterbi"
else:
viterbistring = ""
if (gui == 1):
guistring = "--gui"
else:
guistring = ""
if (dvbs2 == 1):
dvbs2string = "-S2"
else:
dvbs2string = "-S"
if (maxprocess == 1):
maxprocessstring = "--hq"
else:
maxprocessstring = ""
if (hardmetric == 1):
hardmetricstring = "--hard-metric"
else:
hardmetricstring = ""
if (rtldongle0 == 1):
rtlstring = "0"
else:
rtlstring = "1"
srsubstring = f.get()
opslaanfreq= e.get()
fsubstring = float(e.get())
tunesubstring = str(1)
freq = fsubstring * 1000000
freqfinal=int(freq)
freq_lime=str(fsubstring)+"M"
samplerate = int(srsubstring) * 1000
fec = tkvar3.get()
tune = h.get( )
if (rtldongle0 == 1):
if (dvbs2 == 1):
sub = "rtl_sdr -d " + rtlstring + " -f " + str(freqfinal) + " -g " + gain_rtlwaarde + " -s " + str(bandbreedte) + " -p " + str(ppmwaarde) + " - | " + str(leanpad) + "leandvb" + " " + guistring + " " + maxprocessstring + " " + viterbistring + " " + hardmetricstring + " " + fastlockstring + " --tune " + tune + " --standard DVB" + dvbs2string + " --ldpc-helper " + str(leanpad) + "ldpc_tool --inpipe " + str(inpipe_waarde) + " --nhelpers " +str(nhelpers_waarde) + " --sampler rrc --rrc-rej " + str(rrc_rej_factorwaarde) + " -v --roll-off " + str(rolloff_factorwaarde) + " --sr " + str(samplerate) + " -f " + str(bandbreedte) + " | ffplay -v 0 - \n"
else:
sub = "rtl_sdr -d " + rtlstring + " -f " + str(freqfinal) + " -g " + gain_rtlwaarde + " -s " + str(bandbreedte) + " -p " + str(ppmwaarde) + " - | " + str(leanpad) + "leandvb" + " " + guistring + " " + maxprocessstring + " " + viterbistring + " " + hardmetricstring + " " + fastlockstring + " --tune " + tune + " --cr " + str(fec) + " --standard DVB" + dvbs2string + " -v --sr " + str(samplerate) + " -f " + str(bandbreedte) + " | " + str(view) + " - \n"
else:
sub1 = home+"/LimeSuite/builddir/bin/basicRX -a " + antennewaarde + " -r " + bandbreedte_limewaarde + " -g " + gain_limewaarde + " -f " + freq_lime + " -o 16 -b 3000000 &"
sub = "cat ~/experiment | " + str(leanpad) + " " + guistring + " " + maxprocessstring + " " + viterbistring + " " + hardmetricstring + " " + fastlockstring + " --tune " + tune + " --cr " + str(fec) + " --sr " + str(samplerate) + " -f " +bandbreedte_limewaarde + " --s16 | ffplay -v 0 - &"
file = open(home+"/runlean", "w")
file.write("#!/bin/sh \n\n")
file.write(sub1)
file.write("\n\n")
file.write(sub)
file.close()
file = open(home+"/leanlastrun", "w")
file.write(str(opslaanfreq) + "\n")
file.write(srsubstring + "\n")
file.write(fec + "\n")
file.write(tune + "\n")
file.write(str(fastlock) + "\n")
file.write(str(lowsr) + "\n")
file.write(str(viterbi) + "\n")
file.write(str(gui) + "\n")
file.write(str(dvbs2) + "\n")
file.write(str(maxprocess) + "\n")
file.write(str(hardmetric) + "\n")
file.write(str(rtldongle0) + "\n")
file.write(str(rtldongle1) + "\n")
file.write(str(leanpad) + "\n")
file.write(str(ppmwaarde) + "\n")
file.write(str(antennewaarde) +"\n")
file.write(str(gain_limewaarde) +"\n")
file.write(str(bandbreedte_limewaarde) +"\n")
file.write(str(gain_rtlwaarde) + "\n")
file.write(str(viewer_waarde) + "\n")
file.write(str(rolloff_factorwaarde) + "\n")
file.write(str(rrc_rej_factorwaarde) + "\n")
file.write(str(nhelpers_waarde) + "\n")
file.write(str(inpipe_waarde) + "\n")
file.write(tunesubstring + "\n")
file.close()
os.system("sh " + home + "/runlean &")

Button(master,font = "Verdana 11 italic", text='EXIT', command=einde).grid(row=7, column=3,sticky=E)
Button(master, font = "Verdana 11 italic",highlightbackground='red',text='START', command=callback).grid(row=7, column=3,sticky=W)
Button(master, font = "Verdana 11 italic",text='STOP', command=stop).grid(row=7, column=4,sticky=W)
Button(master, font = "Verdana 11 italic",fg='red',highlightbackground='blue',text=' Settings ', command=preset1).grid(row=5, column=3)
#Button(master, font = "Verdana 11 italic",fg='red',highlightbackground='blue',text=' Save Settings ', command=save_parms).grid(row=5, column=3)
#Button(master, font = "Verdana 9 italic",fg='red',highlightbackground='blue',text='UI options', command=preset3).grid(row=2, column=5, ipady=5,sticky=E, ipadx=5)
#Button(master, font = "Verdana 9 italic",fg='red',highlightbackground='blue',text='General Options', command=preset4).grid(row=3, column=5, ipady=5,sticky=E,ipadx=5)

tkvar1 = StringVar(master)

# Frequency Dropdown
choices1 = { '1252','1257','1260','436','437','1255','1252.600','1280','1250','1253'}

tkvar1.set(parameter1[:-1]) # set the default option

popupMenu = OptionMenu(master, tkvar1, *choices1)
Label(master, text=" Frequency ", font = "Verdana 14 italic").grid(row = 0, column = 0)
Label(master, text="MHz", font = "Verdana 14 italic").grid(row = 0, column = 2,sticky=W)
popupMenu.grid(row = 0, column =1, sticky=E)

# on change dropdown value
def change_dropdown1(*args):
print( tkvar1.get() )
e.delete(0, END)
e.insert(0, tkvar1.get())

# link function to change dropdown
tkvar1.trace('w', change_dropdown1)

tkvar2 = StringVar(master)

# SampleRate
choices2 = { '33', '66','125','150','250','333','400','500','600','750','1000','1500','2000','2083','3000','4000','4340','5000'}

tkvar2.set(parameter2[:-1]) # set the default option

popupMenu = OptionMenu(master, tkvar2, *choices2)
Label(master, text=" Samplerate ", font = "Verdana 14 italic").grid(row = 1, column = 0)
Label(master, text="S/R", font = "Verdana 14 italic").grid(row = 1, column = 2,sticky=W)
popupMenu.grid(row = 1, column =1, sticky=E)

# on change dropdown value
def change_dropdown2(*args):
print( tkvar2.get() )
f.delete(0, END)
f.insert(0, tkvar2.get())

# link function to change dropdown
tkvar2.trace('w', change_dropdown2)

tkvar3 = StringVar(master)
# Fec
choices3 = { '1/2','2/3','3/4','5/6','6/7','7/8' }
tkvar3.set(parameter3_conv3)
popupMenu = OptionMenu(master, tkvar3, *choices3)
Label(master, text="FEC (auto@dvbs2)", font = "Verdana 14 italic").grid(row = 2, column = 0)
Label(master, text="Div", font = "Verdana 14 italic").grid(row = 2, column = 2,sticky=W)
popupMenu.grid(row = 2, column =1, sticky=E)

# on change dropdown value
def change_dropdown3(*args):
print( tkvar3.get() )
g.delete(0, END)
g.insert(0, tkvar3.get())

# link function to change dropdown
tkvar3.trace('w', change_dropdown3)

tkvar4 = StringVar(master)
# Tune
choices4 = { '100','500','1000','2000','5000','10000','-100','-500','-1000','-2000','-5000','-10000'}
tkvar4.set(parameter4_conv4) # set the default option

popupMenu = OptionMenu(master, tkvar4, *choices4)
Label(master, text="Tune", font = "Verdana 14 italic").grid(row = 3, column = 0)
Label(master, text="Hz", font = "Verdana 14 italic").grid(row = 3, column = 2,sticky=W)
popupMenu.grid(row = 3, column =1, sticky=E)

# on change dropdown value
def change_dropdown4(*args):
print( )
h.delete(0, END)
h.insert(0, tkvar4.get())

# link function to change dropdown
tkvar4.trace('w', change_dropdown4)

mainloop()

</pre>

----
----
STOP SCRIPT
----
----
Stop Script, copy past in a file, copy it in your home directory and type "chmod +x lean_stop".
<pre>
#/bin/bash

killall rtl_sdr
killall ffplay
killall leandvb
killall basicRX

exit 0

</pre>

[[Bestand:Contellatie8pskleandvb.png]]
----
[[Bestand:8psk_sq6qv.png]]
----
[[Bestand:Db2bg.png]]
----
[[Bestand:Dc0xh.png]]
----
[[Bestand:Dvbs.png]]

Digilite-Raspberry Pi 2x2

2025-03-17T19:32:31Z

Pe2jko:

'''[Hardware]'''
Hierbij de beschrijving van mijn experimenten met RaspBerry PI model B+ en Raspberry Model 2 (v1.1) om IQ signalen door te geven aan bepaald gedeelte van de [http://www.g8ajn.tv/dlindex.html Digilite hardware], met name de Quadrature modulator AD8346. Na het beschikbaar komen van [http://f5oeo.fr/UglyDATV01.pdf UglyDATV] werden daar vrij snel goede resultaten mee behaald. De I en Q signalen van de Raspberry Pi model B+ (v1.2) worden aangeboden op de digilite PCB achter de 74ACT574, en vlak voor het Nyquest filter.Daarbij heb ik weerstanden R6/R8/R9/R10 verwijderd zodat de verbinding naar de 74ACT574 los kwamen te zitten, de PIC processor en de USB waren er al uit, dus uiteindelijk wordt alleen de Quadrature modulator gebruikt. Al vrij snel na het uitkomen van het snellere model [https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ Raspberry PI 2] werden testen gedaan met het creeeren van de benodigde transport streams zodat het idee werd geboren om gebruik te maken van 2 Raspberry PI's. De eerste zorgt voor de DVB-S encoding dmv UglyDATV en de tweede RPI zorgt voor de transport stream. Op deze manier ontstaat een standalone DVB-S zender. De onderlinge communicatie wordt uitgevoerd door een crosslink netwerk kabel. De Raspberry Web camera is aangesloten op de snelste Raspberry PI 2 die dus de stream verzorgt. ''Note :'' testen met andere Nyquest filter waardes (dan 4 Ms/s) lieten zien dat RPI I en Q uitgang onvoldoende gebufferd waren en derhalve geen goede resultaten gaven.

'''[Software]''' voor meer uitleg of vragen mail naar [[Gebruiker:Pe2jko| Joop Koopman]], Haarlem, JO22HI, E-mail address [mailto:JOOPK@HCCNET.NL joopk@hccnet.nl]

In de eerste Raspberry PI ( model b+ ) draait een image van UglyDTV, daarbij maak ik gebruik van MNC ( ik denk een multicast netwerk receiver, was ook bijgeleverd in het UglyDATV image ) en de eigenlijk DVB-S encoder met de juiste pararmeters. 3 regels code :
<pre>
mkfifo /tmp/netfifo
sudo /home/pi/UglyDATV/UglyDATV /tmp/netfifo 2083 1 0 0 &
/home/pi/UglyDATV/mnc -l -i eth0 -p 1234 239.0.0.1 > /tmp/netfifo &
</pre>
De tweede Raspberry PI ( model 2 ) verzorgt de transport stream. De transport stream wordt dmv "tsudpsend" naar het multicast address gestuurd. (makkelijk als je bv dit wilt terug kijken via "mplayer udp://239.0.0.1:1234")
Er worden diverse streams gemaakt allemaal voor specifieke doeleinden. Deze streams worden opgestart / geselecteerd dmv een Wifi (dmv een Wifi dongle in de 2e Raspberry PI ( model 2 ). Een mobiele telefoon als router (Wifi hotspot) zorgt voor de SSH verbinding naar beide Raspberry PI's

'''Voorbeeld''' H.264 stream voor SR 2083, met Webcam en audio via USB audio dongle :
<pre>
mkfifo /tmp/audio2.es
mkfifo /tmp/audio2.pes
mkfifo /tmp/video.es
mkfifo /tmp/video2.ts
mkfifo /tmp/audio2.ts
mkfifo /tmp/mux2.ts
mkfifo /tmp/buffer2.ts
mkfifo /tmp/testbeeld2.es
mkfifo /tmp/testbeeld2.pes
mkfifo /tmp/testbeeld2.ts
sudo nice -n -30 raspivid -s -n -w 720 -h 572 -b 1630000 -t 0 -pf high -fps 25 -g 12 -ih -o /tmp/video.es &
sudo nice -n -30 ffmpeg -analyzeduration 0 -probesize 2048 -r 25 -fpsprobesize 0 -max_delay 40000 -i /tmp/video.es -f h264 -r 25 -minrate 1630k -maxrate 1630k -bufsize 20K -vcodec copy -bufsize 20K -f mpegts -mpegts_original_network_id 1 -mpegts_transport_stream_id 1 -mpegts_service_id 101 -streamid 0:101 -muxrate 1630000 -y /tmp/testbeeld2.es &
sudo nice -n -30 avconv -loglevel quiet -f alsa -i plughw:1 -vn -acodec mp2 -ab 128k -ar 48000 -f mp2 -y /tmp/audio2.es &
/usr/local/bin/esaudio2pes /tmp/audio2.es 1152 48000 384 -1 3600 > /tmp/audio2.pes &
/usr/local/bin/pesaudio2ts 102 1152 48000 384 0 /tmp/audio2.pes > /tmp/audio2.ts &
/usr/local/bin/tscbrmuxer b:188000 /tmp/audio2.ts b:1630000 /tmp/testbeeld2.es b:3008 /home/pi/tables/d_101_102/pat.ts b:1500 /home/pi/tables/d_101_102/pmt.ts b:1500 /home/pi/tables/d_101_102/sdt.ts b:1400 /home/pi/tables/d_101_102/nit.ts o:1919628 /home/pi/null.ts > /tmp/mux2.ts &
/usr/local/bin/tspcrstamp /tmp/mux2.ts 1919628 > /tmp/buffer2.ts &
/usr/local/bin/tsudpsend /tmp/buffer2.ts 239.0.0.1 1234 1919628 &
</pre>

'''Voorbeeld''' MPEG2 stream voor SR 2083, met Webcam still images elke 800 ms en audio via USB audio dongle :
<pre>
mkfifo /tmp/audio2.es
mkfifo /tmp/audio2.pes
mkfifo /tmp/video.es
mkfifo /tmp/video2.ts
mkfifo /tmp/audio2.ts
mkfifo /tmp/mux2.ts
mkfifo /tmp/buffer2.ts
mkfifo /tmp/testbeeld2.es
mkfifo /tmp/testbeeld2.pes
mkfifo /tmp/testbeeld2.ts
raspistill --nopreview -w 720 -h 576 -q 5 -o /tmp/pic.jpg -tl 800 -t 9999999 -th 0:0:0 &
sudo nice -n -30 avconv -loglevel quiet -loop 1 -f image2 -r 1 -i /tmp/pic.jpg -r 25 -an -s 720x576 -aspect 4:3 -vf drawtext=fontsize=44:fontcolor=Yellow:fontfile=/usr/share/fonts/truetype/freefont/FreeSans.ttf:text='PE2JKO D-ATV':x=80:y=60:box=1:boxcolor=0x00000256@0 -b 1300k -vcodec mpeg2video -f mpeg2video -y /tmp/testbeeld2.es &
sudo nice -n -30 avconv -loglevel quiet -f alsa -i plughw:1 -vn -acodec mp2 -ab 128k -ar 48000 -f mp2 -y /tmp/audio2.es &
/usr/local/bin/esvideompeg2pes /tmp/testbeeld2.es > /tmp/testbeeld2.pes &
/usr/local/bin/esaudio2pes /tmp/audio2.es 1152 48000 384 -1 3600 > /tmp/audio2.pes &
/usr/local/bin/pesvideo2ts 101 25 112 1630000 0 /tmp/testbeeld2.pes > /tmp/testbeeld2.ts &
/usr/local/bin/pesaudio2ts 102 1152 48000 384 0 /tmp/audio2.pes > /tmp/audio2.ts &
/usr/local/bin/tscbrmuxer b:188000 /tmp/audio2.ts b:1630000 /tmp/testbeeld2.ts b:3008 /home/pi/tables/v101_a102/pat.ts b:1500 /home/pi/tables/v101_a102/pmt.ts b:1500 /home/pi/tables/v101_a102/sdt.ts b:1400 /home/pi/tables/v101_a102/nit.ts o:1919628 /home/pi/null.ts > /tmp/mux2.ts &
/usr/local/bin/tspcrstamp /tmp/mux2.ts 1919628 > /tmp/buffer2.ts &
/usr/local/bin/tsudpsend /tmp/buffer2.ts 239.0.0.1 1234 1919628 &
</pre>

''PE2JKO uitvoering'', op de foto wordt de Hauppage MPEG2 encoder '''niet''' gebruikt (grote printplaat met tuner blikje).
[[Bestand:RPI-DVB.jpg]]

DVB-S zender met 1x Raspberry PI3 en RPIDATV

2025-03-17T19:31:07Z

Pe2jko:

[[Bestand:Pi3-dvb-screen.png]] [[Bestand:Pi3-dvb-screen2.png]]
----
Schermafbeelding van Python Script VCO lock op 1260 MHz en 2e Schermafbeelding van Python script op 436 Mhz en Multicast stream aktief
----

'''Beschrijving :'''

DVB-S zender op basis van Raspberry PI-3, DVB-S opzet printje van PA0RJV, VCO 35 Mhz-4400 Mhz, software van F5OEO, RPIDATV en besturing van PE2JKO. Enige rvaring met Linux en Raspberry PI is aanbevolen,

'''Bronnen :'''

''Raspberry PI-3 -'' https://www.sossolutions.nl/raspberry-pi-model-3b?gclid=COjLtLXNis4CFcKVGwodEoAK0g

''DVB-S opzet printje PA0RJV -'' http://www.pg540.org/wiki/index.php/SETUP-DATV_DVB-S_Print_for_Raspberry_PI_in_the_English_language

''VCO 35-4400 Mhz ADF4351-development-board op AliExpress'' [http://nl.aliexpress.com/item/35M-4-4G-signal-source-ADF4351-development-board-control-FOR-frequency-sweep/32496544061.html?spm=2114.010208.3.1.PgyQZa&ws_ab_test=searchweb201556_7,searchweb201602_1_10057_10056_10037_10055_10049_301_10059_10058_10032_10017_405_404_106_10040_105_104_10060_103_102,searchweb201603_1&btsid=8839c8b8-0564-416e-877e-bfb9374ef721 ALI ]

''RPIDATV -'' https://github.com/F5OEO/rpidatv

In een vorige bouw beschrijving van een DATV zender heb ik gebruik gemaakt van 2 Raspberry PI computers, een RPI die als modulator dient (met UglyDATV) en een RPI-2 die zorg draagt voor het maken van de streams gebruik makend van multicast. Dit ontwerp is gebaseerd op 1 Raspberry PI-3, die verzorgt de stream en ook de DVB-S modulator en de besturing. Ik maak gebruik van basis elementen welke terug te vinden zijn als bron vermeldingen. Eigen ontwerp is de besturing van VCO en aansturing van de streams. Zal dus op dit gebied proberen te beschrijven wat er gebeurd. Informatie inzake bronvermeldingen is er volop op internet te vinden, daar ga ik hier niet dieper op in.

'''Motivatie:'''

De VCO is een belangrijk onderdeel van een DVB-S zender en frequentie instelling dient eenvoudig te zijn en waar je op kunt vertrouwen, er zijn al voldoende variabelen die succes van DVB-S kunnen beinvloeden, dus VCO moet gewoon werken. Ik wilde dit door de Raspberry PI-3 besturen. Niet gehinderd door enige kennis heb ik het als volgt opgelost, ik heb ervoor gezorgd dat de ingebouwde bleutooth UART van de Raspberry PI-3 wordt uitgeschakeld waardoor UART naar de GPIO pennen kunnen worden gebruikt. Op GPIOpin 14 en 15 kan ik daardoor dmv een programma geschreven in C commandoś sturen naar een Atmega-8 die ik als opsteekprintje op de Raspberry PI-3 heb gemonteerd. Het programma stuurt inhoudt van een file naar die Atmega-8, de ATmega8 ontvangt deze frequentie instellingen en zet de registers van de ADF4351. De VCO vertelt of ie gelocked is en schrijft een file terug op de Raspberry PI-3. Een Python script zorgt nu om het geheel met elkaar samen te laten werken. Het python script is gebouwd om dmv een muis of touch screen in te stellen wat de frequentie moet zijn en welke stream er moet worden opgestart. De besturing is goed leesbaar en daardoor ook aanpasbaar naar je eigen wensen. Een VCO lock of (unlock) wordt grafisch weergegeven door een groene of rode box van de frequentie weergave. Als deze groen is dan is dat een indicatie dat de VCO gelocked is, als het rood is dan is de frequrentie niet in lock en zal DVB-S niet goed worden ontvangen. Op dit moment kun je kiezen uit 7 verschillende streams en 4 verschillende frequenties. Dat is engiszins gelimiteerd, maar voldoende op dit moment voor mijn toepassing, uitbreiding is onbeperkt mogelijk vanwege gebruik van Python.

Wat is belangrijk, het bouwen van het opzet printje voor de Rasperry PI waarop een atmega8 zit, die zit met 5 draden aan de VCO printje van AliExpress, de ADF4351. LE/Data/Clock/MUXOUT/5v/GND. [[Bestand:Screenshot_from_2016-07-25_22-42-45.png|thumb]] Het programma serpush.c leest uit een file (~/freq) de frequentie, die stuurt ie via RS232 naar ATmega8 en die stuurt weer de 5 registers aan afhankelijk van de gewenste frequentie. De source van de ATMEGA8 is ook beschikbaar. Die is door dmv Bascom (Basic Compiler) gemaakt (E-MAIL naar joopk@hccnet.nl). Als de frequentie is ontvangen worden de registers gezet en zal de ADF4351 melden of ie gelocked is, dat stuurt het opzet boardje terug en wordt door de raspberry PI-3 herkent/opgeslagen in de file ~/lock.

'''Gebruikte controle files :'''

''freq'' bepaalt frequentie van VCO (bv 1252.50)

''lock'' bepaalt of VCO gelocked is ( 1 = locked, 0 = unlocked)

''rate'' status geselecteerde stream

Het opzet printje heb ik zodanig gemaakt dat de 5v van de pennen van de GPIO komt, omdat ik een ATMEGA8 gebruik moet ik er wel voor zorgen dat de verbinding naar VCO board dmv een spanningsdeler van 5v naar 3.3 volt gaat want het VCO boardje wil graag 3.3v signalen zien. Ik verbind de de TX van GPIO pin naar de RX van de ATMEGA8 en de RX van de rapsberry PI3 naar de TX van de ATMEGA8. Het opzet printje verzorgt ook de spanning naar het VCO boardje. De ATMEGA8 werkt met een kristal (niet zo kritisch, best = 7,3728 MHz) en heeft een connector om inline te programmeren (ISP). Zodra printje aan gaat zal er worden geluisterd op 300 baud naar de Raspberry PI3, zodra een frequentie wordt ontvangen ( in het formaat xxxx.xx ( 2 cijfers achter de comma ), dwz per 100 Khz ) worden de juiste register waardes berekend om de ADF4351 in te stellen. Het programma op de Raspberry pi-3 genaamd serpush.c ontvangt ook of de VCO gelocked is en als ie gelocked is schrijft ie een 1 in de file ~/lock. Dus in 1 sessie wordt frequentie doorgegeven aan de ATMEGA8 en de ATMEGA8 stuurt de lock status weer terug. Dat is alles.

== Sources ==

''Source serpush.c, compileren dmv commando = cc serpush.c -o serpush''
<pre>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>

int main(int argc, char ** argv) {

int fdr;

fdr = open("/home/pi/freq",O_RDONLY);
if (fdr == -1) {
perror("open_port: Unable to open /home/pi/freq - ");
return(-1);
}
char buf1[256];
int n1;
n1 = read(fdr, (void*)buf1, 255);
if (n1 < 0) {
perror("Read failed - ");
return -1;
} else if (n1 == 0) printf("No data on port\n");
else {
buf1[n1] = '\0';
printf("%i bytes read : %s", n1, buf1);
}

int fd = open_port();
change_bps(fd);

// Write to the port
int n = write(fd,buf1,9);
if (n < 0) {
perror("Write failed - ");
return -1;
}

// Read up to 255 characters from the port if they are there
char buf[256];
n = read(fd, (void*)buf, 255);
if (n < 0) {
perror("Read failed - ");
return -1;
} else if (n == 0) printf("No data on port\n");
else {
buf[n] = '\0';
printf("%i bytes read : %s", n, buf);
}

// Don't forget to clean up
close(fd);
close(fdr);

}

void change_bps(int fd)
{
struct termios options;

/*
* Get the current options for the port...
*/

tcgetattr(fd, &options);

/*
* Set the baud rates to ...
*/

cfsetispeed(&options, B300);
cfsetospeed(&options, B300);
tcsetattr(fd, TCSADRAIN, &options);

}

int
open_port(void)
{
int fd; /* File descriptor for the port */
fd = open("/dev/ttyAMA0", O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1)
{
perror("open_port: Unable to open /dev/ttyS0 - ");
}
else
fcntl(fd, F_SETFL, 0);
return (fd);
}

</pre>

----

'''Python besturing source, hiermee kun je dmv de muis of touchscreen de juiste stream selecteren en de juiste frequentie instellen. :'''

----

<pre>
import Tkinter
import subprocess
import time

from Tkinter import *
from Tkinter import BOTH, W, NW, SUNKEN, TOP, X, FLAT, LEFT

top = Tkinter.Tk()

time1 = ''
clock = Label(top, font=('Purisa', 12), bg='powder blue')
clock.pack(fill=BOTH, expand=1)

def tick():
global time1
time2 = time.strftime('%H:%M:%S')
if time2 != time1:
time1 = time2
clock.config(text=time2)
clock.after(200, tick)

def helloCallBack():
subprocess.call('/home/pi/Desktop/436000', shell=True)
text = openInstrucktion()
W.insert("1.0", text)
W.insert("1.10", " MHz")
resultaat = lock()
if resultaat == "LOCKED":
W.tag_add("here","1.0", END)
W.tag_config("here", background = "green2")
else:
W.tag_add("here","1.0", END)
W.tag_config("here", background = "red")

def helloCallBack2():
subprocess.call('/home/pi/Desktop/1257000', shell=True)
text = openInstrucktion()
W.insert("1.0", text)
W.insert("1.10", " MHz")
resultaat = lock()
if resultaat == "LOCKED":
W.tag_add("here","1.0", END)
W.tag_config("here", background = "green2")
else:
W.tag_add("here","1.0", END)
W.tag_config("here", background = "red")

def helloCallBack3():
subprocess.call('/home/pi/Desktop/1260000', shell=True)
text = openInstrucktion()
W.insert("1.0", text)
W.insert("1.10", " MHz")
resultaat = lock()
if resultaat == "LOCKED":
W.tag_add("here","1.0", END)
W.tag_config("here", background = "green2")
else:
W.tag_add("here","1.0", END)
W.tag_config("here", background = "red")

def helloCallBack4():
subprocess.call('/home/pi/Desktop/1252500', shell=True)
text = openInstrucktion()
W.insert("1.0", text)
W.insert("1.10", " MHz")
resultaat = lock()
if resultaat == "LOCKED":
W.tag_add("here","1.0", END)
W.tag_config("here", background = "green2")
else:
W.tag_add("here","1.0", END)
W.tag_config("here", background = "red")

def helloCallBack5():
subprocess.call('/home/pi/Desktop/sr2000-X11', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "orange")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "light grey")

def helloCallBack6():
subprocess.call('/home/pi/Desktop/sr2000-testbeeld', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "orange")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "light grey")

def helloCallBack7():
subprocess.call('/home/pi/Desktop/sr2000-testbeeld-hamradio', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "orange")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "light grey")

def helloCallBack8():
subprocess.call('/home/pi/Desktop/sr2083-X11', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "orange")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "light grey")

def helloCallBack9():
subprocess.call('/home/pi/Desktop/sr2083-testbeeld', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "orange")
K.configure(background = "light grey")
L.configure(background = "light grey")

def helloCallBack10():
subprocess.call('/home/pi/Desktop/sr250-X11-fec12', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "orange")
L.configure(background = "light grey")

def helloCallBack11():
subprocess.call('/home/pi/Desktop/sr250-X11-fec78', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "orange")

def openInstrucktion():
f= open("/home/pi/freq")
text = f.read()
return text
def openInstrucktion2():
f= open("/home/pi/rate")
text2 = f.read()
return text2

def lock():
f= open("/home/pi/lock")
text3 = f.read()
if text3 == "1\n":
resultaat = "LOCKED"
else:
resultaat = "UNLOCKED"
return resultaat

def blink(rectangle, canvas):
for i in range(3):
canvas.itemconfigure(rectangle, fill = "red")
sleep(1)
canvas.itemconfigure(rectangle, fill = "white")
sleep(1)

def helloCallBack99():
subprocess.call('/home/pi/Desktop/stop', shell=True)
text2 = openInstrucktion2()
V.insert("1.0", text2)
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
F.configure(background = "light grey")
G.configure(background = "light grey")
H.configure(background = "light grey")
I.configure(background = "light grey")
J.configure(background = "light grey")
K.configure(background = "light grey")
L.configure(background = "light grey")

canvas = Canvas(width = 300, height = 50, bg = 'powder blue')
canvas.pack(expand = YES, fill = BOTH)
canvas.create_text(5,25 ,anchor= "w" ,font=("Purisa",20), text= "PE2JKO, D-ATV Raspberry PI 3")

B = Tkinter.Button(top, text ="436 MHz", font=("Helvetica",12), command = helloCallBack)
C = Tkinter.Button(top, text ="1257 MHz", font=("Helvetica",12), command = helloCallBack2)
D = Tkinter.Button(top, text ="1260 MHz", font=("Helvetica",12), command = helloCallBack3)
E = Tkinter.Button(top, text ="1252.60 MHz", font=("Helvetica",12), command = helloCallBack4)
F = Tkinter.Button(top, text ="2000KS/s X11", font=("Helvetica",14), command = helloCallBack5)
G = Tkinter.Button(top, text ="2000KS/s TESTBEELD", font=("Helvetica",14), command = helloCallBack6)
H = Tkinter.Button(top, text ="2000KS/s TESTBEELD HAMRADIO", font=("Helvetica",14), command = helloCallBack7)
I = Tkinter.Button(top, text ="2083KS/s X11", font=("Helvetica",14), command = helloCallBack8)
J = Tkinter.Button(top, text ="2083KS/s TESTBEELD", font=("Helvetica",14), command = helloCallBack9)
K = Tkinter.Button(top, text ="250 KS/s X11 FEC 1/2", font=("Helvetica",14), command = helloCallBack10)
L = Tkinter.Button(top, text ="250 KS/s X11 FEC 7/8", font=("Helvetica",14), command = helloCallBack11)
Z = Tkinter.Button(top, text ="STOP", fg="red", font=("Helvetica-bold",18),command = helloCallBack99)
text = openInstrucktion()
text2 = openInstrucktion2()

resultaat = lock()
if resultaat == "LOCKED":
W = Text(top ,height=1, bg = "green2", width=11,font=("Helvetica",32))
else:
W = Text(top ,height=1, bg = "red", width=11,font=("Helvetica",32))
W.insert("1.0", text)
W.insert("1.10", " MHz")

V = Text(top ,height=1, bg = "light grey", fg = "blue", width=18,font=("Helvetica",28))
V.tag_configure("center", justify='center')
V.tag_add("center", 1.0, "end")
V.insert(END,text2, "center")
W.pack()
V.pack()
F.pack(fill=X)
G.pack(fill=X)
H.pack(fill=X)
I.pack(fill=X)
J.pack(fill=X)
K.pack(fill=X)
L.pack(fill=X)
Z.pack(fill=X)
B.pack(in_=top, side=LEFT)
C.pack(in_=top, side=LEFT)
D.pack(in_=top, side=LEFT)
E.pack(in_=top, side=LEFT)

tick()
top.mainloop()

</pre>

----

'''Voorbeeldscript om stream aan te roepen en in een controlfile de naam te plaatsen :'''

----

<pre>
#!/bin/sh
#
sudo /home/pi/stop
echo "2000 Ks/s, FEC 1/2" > /home/pi/rate
/home/pi/sr2000-x11-direct
</pre>

----

'''Voorbeeldscript om frequentie aan te passen :'''

----

<pre>
#!/bin/sh

echo "436.00" > /home/pi/freq
/home/pi/serpush | tail -c 2 | cat - > /home/pi/lock
sleep 1
/home/pi/serpush | tail -c 2 | cat - > /home/pi/lock
exit
</pre>

----

'''Voorbeeldscript om stream op te starten, in dit geval een stukje desktop (X11grab) (''opgepast'' is een hele lange string!!, berekend voor 250Ks/s) :'''

----

<pre>
#!/bin/sh

mkfifo /tmp/video2.ts

sudo nice -n -30 arecord -f S16_LE -r 48000 -c 1 -M -D plughw:1 | sudo nice -n -30 ffmpeg -itsoffset -00:00:0.8 -analyzeduration 0 -probesize 2048 -fpsprobesize 0 -ac 1 -thread_queue_size 512 -i - -f x11grab -i :0.0+0,0 -framerate 25 -video_size 300x288 -fflags nobuffer -s 300x288 -b:v 200k -minrate:v 200k -maxrate:v 200k -vcodec mpeg2video -blocksize 1880 -strict experimental -async 2 -acodec mp2 -ab 32K -ar 48k -ac 1 -flags -global_header -f mpegts -blocksize 1880 -mpegts_original_network_id 1 -mpegts_transport_stream_id 1 -mpegts_service_id 1 -mpegts_pmt_start_pid 1001 -mpegts_start_pid 101 -metadata service_provider=PE2JKO -metadata service_name=PE2jko -muxrate 230392 -y /tmp/video2.ts &

sudo /home/pi/rpidatv/bin/rpidatv -i /tmp/video2.ts -s 250 -c 1/2 -m IQ -f 0 -x 12 -y 13 &

exit 0
</pre>

Portsdown4 Node-red interface

2025-03-17T19:29:24Z

Pe2jko:

'''Portsdown4 Node-red interface'''

'''Info @''' joopk@hccnet.nl

'''Hardware Equipment used :'''

*Raspberry PI4

'''Software used :'''

*Raspberry PI OS with Desktop and recommended Software

*Installed remote desktop "xrdp" on RPI

*Portsdown4 Software from Github [[https://github.com/BritishAmateurTelevisionClub/portsdown4]]

In the OS by default Node-Red is included, I only added the [[https://flows.nodered.org/node/node-red-dashboard UI Buttons]]

Portsdown4 configuration and settings normally are done via Touchscreen. Portsdown4 have many settings and currently I only need few main settings, this I added to a small dashboard. The setup is simple, first I create a set of "default" config parameters in the flow. Then at same time I read /home/pi/rpidatv/scripts/portsdown_config.txt and each line will be split and feed to the correct UI interface. When there is a change of 1 of parameters I write the full set of flow parameters back to same file. ( /home/pi/rpidatv/scripts/portsdown_config.txt ). I added few extra buttons to restart Portsdown4 or Shutdown the PI. I haven't added all touchscreen buttons and options, only the ones currently needed are in.

So in few steps :
*Install OS
*Install rdpx (optional)
*Install Portsdown4
*Setup Portsdown4 with your settings like call
*Check if it works
*Enable Node-Red to start when booting
*Add Node-red UI Buttons
*Import the Flow
*Open the Webpage of the UI

In case more settings are required please let me know.

[[Bestand:Node-red1-portsdown.JPG]]

The FLOW, if you need the json, let me know.

[[Bestand:Node-red2-portsdown.JPG]]

RFE for PlutoDVB2

2023-07-22T17:31:08Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' pe2jko@pg540.org

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

'''Update''' : Michel de HB9DUG added a flow which links to the Receiver flow. The original receive frequency was selectable only with dropdown menu. This is not so flexible, Michel took the output of our [https://github.com/m0dts/QO-100-WB-Live-Tune QuickTune tool] and linked it to the Frequency and Samplerate input. So if you click on a station in Quicktune, the tuner will move freq and set correct Samplerate. Thanks Michel. Please see below the flow from Michel.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]

QuickTune interface flow chart from Michel HB9DUG which links to freq input and samplerate input controlling the DATV Tuner connected to Pluto.

[[File:Hb9dug-ext.jpg]]

RFE for PlutoDVB2

2023-07-22T17:30:17Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' pe2jko@pg540.org

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

'''Update''' : Michel de HB9DUG added a flow which links to the Receiver flow. The receive frequency was selectable only with dropdown menu. This is not so flexible, Michel took the output of our [https://github.com/m0dts/QO-100-WB-Live-Tune QuickTune tool] and linked it to the Frequency and Samplerate input. So if you click on a station in Quicktune, the tuner will move freq and set correct Samplerate. Thanks Michel. Please see below the flow from Michel.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]

QuickTune interface flow chart from Michel HB9DUG which links to freq input and samplerate input controlling the DATV Tuner connected to Pluto.

[[File:Hb9dug-ext.jpg]]

RFE for PlutoDVB2

2023-07-22T17:29:55Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' pe2jko@pg540.org

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

Update : Michel de HB9DUG added a flow which links to the Receiver flow. The receive frequency was selectable only with dropdown menu. This is not so flexible, Michel took the output of our [https://github.com/m0dts/QO-100-WB-Live-Tune QuickTune tool] and linked it to the Frequency and Samplerate input. So if you click on a station in Quicktune, the tuner will move freq and set correct Samplerate. Thanks Michel. Please see below the flow from Michel.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]

QuickTune interface flow chart from Michel HB9DUG which links to freq input and samplerate input controlling the DATV Tuner connected to Pluto.

[[File:Hb9dug-ext.jpg]]

Bestand:Hb9dug-ext.jpg

2023-07-22T17:26:52Z

Pe2jko:

RFE for PlutoDVB2

2023-07-22T17:25:46Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' pe2jko@pg540.org

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

Update : Michel de HB9DUG added a flow which links to the Receiver flow. The receive frequency was selectable only with dropdown menu. This is not so flexible, Michel took the output of our QuickTune tool and linked it to the Frequency and Samplerate input. So if you click on a station in Quicktune, the tuner will move freq and set correct Samplerate. Thanks Michel. Please see below the flow from Michel.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]

RFE for PlutoDVB2

2023-07-22T17:21:45Z

Pe2jko:

Radio Front-End for PlutoDVB2 from F5OEO

'''Info @''' pe2jko@pg540.org

This radio front-end is created to experiment with DATV Pluto firmware V2 from F5OEO (Evariste). The firmware is mainly controlled via [https://en.wikipedia.org/wiki/MQTT MQTT messaging], and there are many MQTT clients available to control this firmware. One of the clients is Node-Red which I use for some time for many other projects to control devices which I use for the hobby. Due to the many improvements and features I needed a simple user-interface to control this Firmware. This resulted in this basic front-end. It controls the transmitter and controls the receiver in case a DATV tuner is connected to Pluto. In case Tutione tuner is connected the received stream is redirected 230.0.0.2 on port1234. So this can be made visible for example with command '''ffplay udp://230.0.0.2:1234 ''' or VLC pointing to that URL.
Let me know if you would like to receive the flows, please send me a mail.

----

'''Main components''' : Node-Red, UI Dashboard.
'''Installed on''' Raspberry PI4.

----

[[File:Rfe-plutodvb2-2.jpg ]]

When the new firmware is loaded to the Pluto it is needed to add your Callsign one time in order the RFE to talk to Pluto. Therefore you can make an SSH connection using Putty for example to Pluto. Issue the command '''fw_setenv call YourCall''', then '''reboot''' the Pluto. Then the flow should be able to talk with Pluto.
As every installation is different the correct IP address has to be entered in the MQTT node in Node-red.

In the flow search for following icon and double-click :
[[File:Mqtt-icon.jpg]]

Then select the edit button to define name and IP address, fill in your address from the Pluto :

[[File:Mqtt-icon2.jpg]]

The click on Update.

[[File:Mqtt-icon3.jpg]]

Please see my current hardware setup:

[[File:Plutdvb2-schematic.jpg]]