Date   

Re: Test sdrangel port for Mac OSX Mojave #osx

Gaston LU5AGQ
 

On my side I must say that Ziga's version always worked with my HackRF as well as the BladeRF.

The only down side is that no matter when or how, everytime I hover the mouse over the SDRangel window the audio starts stuttering.

Best regards

On Thu, Mar 14, 2019 at 10:12 AM Žiga S. <ziga.svetina@...> wrote:
Hi everybody,

I post SDRangel v4.5.0 - osx with Qt 5.12.1 Sierra build,
please find the DMG here.

In the meantime I am preparing my MojaveVM,
to get some initial docs or some script to set-up build environments quicker.

Cheerz, Z




Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Marty Wittrock
 

Edouard,

Understood - I know that the maintenance of code that is unique is a real headache and that it makes best sense to keep the core functionality and add all the other features separately through the REST API. It would be good to see a 'molecular level' (thorough) implementation of this if possible and documented such that we can be proficient. We're all not as intelligent on this as you are... :)

73 de Marty, KN0CK


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Marty Wittrock
 

James,

Thanks in advance for putting that together. I would try myself, but at the moment I'm trying to get my Lime-Mini sane again through programming the firmware manually using a Byte Blaster and then (if it's working) read the 'Mini power levels over the 160m (1.8 MHz) to 25cm (1.28 GHz) region. I do appreciate the effort because I'm trying hard to get the Lime functional half duplex for WSPR and FT-8 - that's the direction I'm going for the moment for the other Hams out there that have been waiting for this to happen. So please do keep me advised on the progress there.

I will also say that the USB relay you ordered is the same one I have, too - you will find that the USB relay plugs in and looks like a COM port (whatever the PC assigns to it) and it will have the following ON/OFF serial command string:

ON (PTT KEYED): 0xA0 0x01 0x01 0xA2

OFF (PTT RELEASED): 0xA0 0x01 0x00 0xA1

Notice that the first two bytes of each message are identical - it's the final two bytes of each that is different and switches the relay ON or OFF as is commanded by the strings above. 

Again, keep me advised of what you find on this, James - much appreciate the effort on this - 

73 de Marty, KN0CK

 


Re: Quick question re: API

James Dallas
 

Thanks. I'll play with it and report back.


On Thu, Mar 14, 2019, 12:33 PM Edouard Griffiths <f4exb06@...> wrote:
Hi James,

see: https://restfulapi.net/statelessness/ so there are no persistent connections you can rely on to store some client context. The internal httplib uses a pool of connections that get released only after a certain amount of time so I think this is handled in a pretty sensible way. You can check the log in debug mode to follow what happens with connections.

Brgds, Edouard.


Re: Quick question re: API

Edouard Griffiths
 

Hi James,

see: https://restfulapi.net/statelessness/ so there are no persistent connections you can rely on to store some client context. The internal httplib uses a pool of connections that get released only after a certain amount of time so I think this is handled in a pretty sensible way. You can check the log in debug mode to follow what happens with connections.

Brgds, Edouard.


Quick question re: API

James Dallas
 

Hi team,

Does anyone know if the web server component of sdrangel (for the REST API) allows persistent connections / keep-alives?

I had heretofore assumed that each API call was atomic and would require its own connection, but obviously that means the overhead of constantly creating and trashing connections. Performance would be faster if we could re-use a single connection for multiple API requests.

Thanks,

James AD5NL


Re: Test sdrangel port for Mac OSX Mojave #osx

Žiga S.
 

Hi everybody,

I post SDRangel v4.5.0 - osx with Qt 5.12.1 Sierra build,
please find the DMG here.

In the meantime I am preparing my MojaveVM,
to get some initial docs or some script to set-up build environments quicker.

Cheerz, Z


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Siegfried Jackstien
 

Am 14.03.2019 um 03:49 schrieb James Dallas:
To Marty's point, I was thinking about making a small utility to listen for reverse API requests and then use that to trigger USB relays. The problem is that in shopping today I noticed there are at least three different kinds of relays on Amazon (FTDI/CH based USB-to-serial devices as well as devices using the HID API). Not to mention that a more creative person might, say, bang together an arduino or raspberry pi with a relay hat.

nice idea to make a software that listen to api and trigger relay ...



The more I think about the logistics -- and I was one of the people originally begging him on this issue! -- the more I realize that Edouard's position is the most sane one. Not because the work would be hard per se (I'm not a programmer) but because supporting every hardware combination imaginable would very quickly get to be tedious and waste time he might better spend supporting the core of sdrangel.

that is why hdsdr programmers went the extio drivers route ... hardware builder has to add an extio driver to his hardware ... no need to reprogramm hdsdr for a new hardware

greetz

sigi dg9bfc


Re: Test sdrangel port for Mac OSX Mojave #osx

Žiga S.
 

Hi,

HackRF works flawlessly with Firmware Version: 2018.01.1 (API:1.02)

But I have built and tested on Sierra.
Next thing to try out is my new build environment in Mojave.
Will document all of my steps which were involved to get packaged DMG.

If someones interest to test my build, let me know...
Otherwise will produce fresh one from MojaveVM.

Cheerz, Z


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Siegfried Jackstien
 

https://www.amazon.com/clouddrive/share/8Qn3vw8915JaZiv5bYzuBJWg1Ic4kibOcus1BhTJcrS/zab_iPx5TeW5JphOThxVQg

relay driver software

If you nedd the soft and C++ code to control this device, just contact us on amazon!(copy fro this device)

https://www.amazon.com/KNACRO-1-Channel-Module-Square-interface/dp/B071VJ628X/ref=sr_1_5?keywords=usb+relay&qid=1552537092&refinements=p_36%3A1253503011&rnid=386442011&s=electronics&sr=1-5

.....this seems to use the hid driver................................

.............

<https://www.amazon.com/LM-YN-2-Channel-Module-Control/dp/B075GLQQC9/ref=sr_1_7?keywords=usb+relay&qid=1552537092&refinements=p_36%3A1253503011&rnid=386442011&s=electronics&sr=1-7

and this uses ch340 usb sewrial contro chip (installs as a comport) ... and you send the right comand in the right speed to that comport

....

so there are hid boards ... and so to speak com port boards

greetz

sigi dg9bfc


Am 14.03.2019 um 03:58 schrieb James Dallas:

FYI this is one of the two gizmos I ordered today, and I think based on Marty's description the one he is using:

https://www.amazon.com/SMAKN%C2%AE-LCUS-1-module-intelligent-control/dp/B01CN7E0RQ/

The basic plan is to see if I can adapt the existing reverse API python script to send the serial commands instead of just echoing to console.

If I get this working (I am expecting delivery on Friday or Saturday and see this as maybe a three hour coding project), will upload to github and update the group.

I also ordered a SainSmart 4-relay board, and have a couple of the HID API boards from previous projects sitting out in the garage.

On Wed, Mar 13, 2019 at 10:49 PM James Dallas via Groups.Io <jim.dallas=gmail.com@groups.io> wrote:
To Marty's point, I was thinking about making a small utility to listen for reverse API requests and then use that to trigger USB relays. The problem is that in shopping today I noticed there are at least three different kinds of relays on Amazon (FTDI/CH based USB-to-serial devices as well as devices using the HID API). Not to mention that a more creative person might, say, bang together an arduino or raspberry pi with a relay hat.

The more I think about the logistics -- and I was one of the people originally begging him on this issue! -- the more I realize that Edouard's position is the most sane one. Not because the work would be hard per se (I'm not a programmer) but because supporting every hardware combination imaginable would very quickly get to be tedious and waste time he might better spend supporting the core of sdrangel.

On Wed, Mar 13, 2019 at 10:27 PM Edouard Griffiths <f4exb06@...> wrote:
Hello Marty,

I think this has been discussed already a long time ago and eventually I came up with the idea of a REST API. "It would greatly simplify this whole issue" may be for you but not for me (the author) nor any contributor to the code. If you have a specific hardware then it is up to you to deal with it and integrate it with SDRangel in a bigger bundle. Making it part of the mainstream code would import bloats of code unrelated to the prime purpose of SDRangel and make it even harder to read and harder to maintain than it is today. So unless someone forks out the project this is not going to happen.

Brgds, Edouard.


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Michael Durkin
 

i think that just an output of frequency and Tx/Rx status is the
minimum to a serial device

On 3/13/19, James Dallas <jim.dallas@gmail.com> wrote:
To Marty's point, I was thinking about making a small utility to listen for
reverse API requests and then use that to trigger USB relays. The problem
is that in shopping today I noticed there are at least three different
kinds of relays on Amazon (FTDI/CH based USB-to-serial devices as well as
devices using the HID API). Not to mention that a more creative person
might, say, bang together an arduino or raspberry pi with a relay hat.

The more I think about the logistics -- and I was one of the people
originally begging him on this issue! -- the more I realize that Edouard's
position is the most sane one. Not because the work would be hard per se
(I'm not a programmer) but because supporting every hardware combination
imaginable would very quickly get to be tedious and waste time he might
better spend supporting the core of sdrangel.

On Wed, Mar 13, 2019 at 10:27 PM Edouard Griffiths <f4exb06@gmail.com>
wrote:

Hello Marty,

I think this has been discussed already a long time ago and eventually I
came up with the idea of a REST API. "It would greatly simplify this
whole
issue" may be for you but not for me (the author) nor any contributor to
the code. If you have a specific hardware then it is up to you to deal
with
it and integrate it with SDRangel in a bigger bundle. Making it part of
the
mainstream code would import bloats of code unrelated to the prime
purpose
of SDRangel and make it even harder to read and harder to maintain than
it
is today. So unless someone forks out the project this is not going to
happen.

Brgds, Edouard.





Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

James Dallas
 

FYI this is one of the two gizmos I ordered today, and I think based on Marty's description the one he is using:

https://www.amazon.com/SMAKN%C2%AE-LCUS-1-module-intelligent-control/dp/B01CN7E0RQ/

The basic plan is to see if I can adapt the existing reverse API python script to send the serial commands instead of just echoing to console.

If I get this working (I am expecting delivery on Friday or Saturday and see this as maybe a three hour coding project), will upload to github and update the group.

I also ordered a SainSmart 4-relay board, and have a couple of the HID API boards from previous projects sitting out in the garage.

On Wed, Mar 13, 2019 at 10:49 PM James Dallas via Groups.Io <jim.dallas=gmail.com@groups.io> wrote:
To Marty's point, I was thinking about making a small utility to listen for reverse API requests and then use that to trigger USB relays. The problem is that in shopping today I noticed there are at least three different kinds of relays on Amazon (FTDI/CH based USB-to-serial devices as well as devices using the HID API). Not to mention that a more creative person might, say, bang together an arduino or raspberry pi with a relay hat.

The more I think about the logistics -- and I was one of the people originally begging him on this issue! -- the more I realize that Edouard's position is the most sane one. Not because the work would be hard per se (I'm not a programmer) but because supporting every hardware combination imaginable would very quickly get to be tedious and waste time he might better spend supporting the core of sdrangel.

On Wed, Mar 13, 2019 at 10:27 PM Edouard Griffiths <f4exb06@...> wrote:
Hello Marty,

I think this has been discussed already a long time ago and eventually I came up with the idea of a REST API. "It would greatly simplify this whole issue" may be for you but not for me (the author) nor any contributor to the code. If you have a specific hardware then it is up to you to deal with it and integrate it with SDRangel in a bigger bundle. Making it part of the mainstream code would import bloats of code unrelated to the prime purpose of SDRangel and make it even harder to read and harder to maintain than it is today. So unless someone forks out the project this is not going to happen.

Brgds, Edouard.


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

James Dallas
 

To Marty's point, I was thinking about making a small utility to listen for reverse API requests and then use that to trigger USB relays. The problem is that in shopping today I noticed there are at least three different kinds of relays on Amazon (FTDI/CH based USB-to-serial devices as well as devices using the HID API). Not to mention that a more creative person might, say, bang together an arduino or raspberry pi with a relay hat.

The more I think about the logistics -- and I was one of the people originally begging him on this issue! -- the more I realize that Edouard's position is the most sane one. Not because the work would be hard per se (I'm not a programmer) but because supporting every hardware combination imaginable would very quickly get to be tedious and waste time he might better spend supporting the core of sdrangel.

On Wed, Mar 13, 2019 at 10:27 PM Edouard Griffiths <f4exb06@...> wrote:
Hello Marty,

I think this has been discussed already a long time ago and eventually I came up with the idea of a REST API. "It would greatly simplify this whole issue" may be for you but not for me (the author) nor any contributor to the code. If you have a specific hardware then it is up to you to deal with it and integrate it with SDRangel in a bigger bundle. Making it part of the mainstream code would import bloats of code unrelated to the prime purpose of SDRangel and make it even harder to read and harder to maintain than it is today. So unless someone forks out the project this is not going to happen.

Brgds, Edouard.


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Edouard Griffiths
 

Hello Marty,

I think this has been discussed already a long time ago and eventually I came up with the idea of a REST API. "It would greatly simplify this whole issue" may be for you but not for me (the author) nor any contributor to the code. If you have a specific hardware then it is up to you to deal with it and integrate it with SDRangel in a bigger bundle. Making it part of the mainstream code would import bloats of code unrelated to the prime purpose of SDRangel and make it even harder to read and harder to maintain than it is today. So unless someone forks out the project this is not going to happen.

Brgds, Edouard.


Re: Test sdrangel port for Mac OSX Mojave #osx

Žiga S.
 



Made a build using fresh sdrangel sources, 
I will test tomorrow with HackRF, then will move to fresh Qt & other deps.

Cheerz, Z


Re: Test sdrangel port for Mac OSX Mojave #osx

Žiga S.
 

Hi Fabio,

to explain some of your statements:

* Information about how to compile on OSX was definitely too short (Release build configuration with QT Creator ... that's it) 

I Agree, one day I decided to port/compile sources for OSX ... while I have hackRF.
Who needs documentation first time? second time....?
When I would be satisfied with the whole build process, I would write concrete documentation, sorry for my seek for shortcuts :)

* It is not clear if the sdrangel Application provide on its code all hardware libraries need for every devices or is dependent on other packages to be present and where they has to be found 

You are right, I have not provided my build machine's info details in docs.

* Since many library are dynamic it is clear that you have to install other code before program run but this information is not so evident to people that normally do only (config, make and make install)
You would do this normally for each application, but as I experienced the whole compilation process:
It is not that big, but it's not that tiny either, so first time packaging with whole DMG aspect it's quite tricky,
since most of the versions will or can be different regarding you could have 3 or 4 sources of dylib version compilations(macports/brew/native/self-build)
In a perfect world I would just compile everything from scratch with proper version, but then you have libusb, which should be osx specific.
This were my consideration after the DMG, so my next step would be, to go to fresh MojaveVM and provide once again the build process,
with maybe more standardized way, self-build everything, only native hw-libs should be linked differently.
Step2(maybe) port to other more clean build-process, like cmake which is already there ...

* The compiled binary rely on a specific library version and it is necessary to edit the .pro files and set all paths in the right way. 
It depends what is linking your dylibs, in my case was using Qt's deployment tool to override with @rpath.


* it should be nice to develop an abstraction layer that overcomes the need to recompile if some library has to be upgraded, probably exposing a common interface
I would think this is not so needed, as I see linux builds, would rather port the whole build process to cmake.
Otherwise gradle or Android Build system (*.mk) is also an old/ugly option :)

To summarise your comments, I have started this OSX port as a joke few years ago,
and then each time there was some fresh major version, I recompiled ... so 2.x, 3.x, 4.x.
With v4 I actually packaged DMG and I just went the protocol,
if macports does not provide the dependency, then I will compile my own ...
and v2 was only but Qt .pro files :)
and to my knowledge v2 or v3 was only used by me @MacOS :{

Thanks for your comments,
and I hope we will have someday better CI on OSX... maybe with your help?

Cheerz, Z


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

James Dallas
 

Hi Marty,

I've ordered something that I believe is similar off of Amazon and I am going to try to bash something together this weekend.

Re: monitoring the com port for ptt status, I sent an email about using statserial on Linux. I am going to see if there might be something better...

On Wed, Mar 13, 2019, 5:19 PM Marty Wittrock <martywittrock@...> wrote:

[Edited Message Follows]

James / Mike,

The relay I'm using (which are abundant here in the US - very different than the 'MagiDeal' USB relays that they have in the U.K.) has the following qualities:

The USB relay I have (and bought off EBay and they're also on Amazon) acts like a COM port device and requires the following command strings to engage/disengage the relay:

ON = 0xA0 0x01 0x01 0xA2

OFF = 0xA0 0x01 0x00 0xA1

...meaning, that if the relay was seen by Windows as a COM6 device, you would send the PTT-ON string of: 0xA0 0x01 0x01 0xA2  ..on COM 6. and similarly, you'd send the PTT-OFF string of: 0xA0 0x01 0x00 0xA1 on the same COM port, COM 6. 

All I'm looking for is a way to do this when SDRAngel enters transmit such that the relay can switch over from the Rx1W port on the Lime to the Tx1L port. 

Also, if an application is running - like WSJT-X - currently there are no 'radio' provisions to make SDRAngel receive or transmit from that app (WSJT-X). I suppose one could hijack the serial port commands for any radio (let's say, Kenwood) and then look for the PTT command somehow from the app communicating to (presumably) a COM port that's been set up in the app (again, WSJT-X) and sniff it out using a virtual comport app. That would be the way to fire the PTT relay and I would think there's got to be some way of taking the transmit and receive and start/stopping those to get half-duplex. This is where my research is at the time, but I'm not savvy enough with the REST API to make any of this happen right now. I could just as easily do all this in hardware just using the Line-Out function of the PC when WSJT-X wants to go into transmit and have the relay switch to the right port, but it means that the transmit function has to run all the time in SDRAngel and you only use a Upper Sideband modulator and the audio from Line-Out to make the whole thing work...The only clunky thing about it is that the transmit has to run the whole time in 'Angel unless there's a way to shut it off like real half duplex radios do.

...Wish there was a way to do this through 'Angel...It would greatly simplify this whole issue. 

73 de Marty KN0CK


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Marty Wittrock
 
Edited

James / Mike,

The relay I'm using (which are abundant here in the US - very different than the 'MagiDeal' USB relays that they have in the U.K.) has the following qualities:

The USB relay I have (and bought off EBay and they're also on Amazon) acts like a COM port device and requires the following command strings to engage/disengage the relay:

ON = 0xA0 0x01 0x01 0xA2

OFF = 0xA0 0x01 0x00 0xA1

...meaning, that if the relay was seen by Windows as a COM6 device, you would send the PTT-ON string of: 0xA0 0x01 0x01 0xA2  ..on COM 6. and similarly, you'd send the PTT-OFF string of: 0xA0 0x01 0x00 0xA1 on the same COM port, COM 6. 

All I'm looking for is a way to do this when SDRAngel enters transmit such that the relay can switch over from the Rx1W port on the Lime to the Tx1L port. 

Also, if an application is running - like WSJT-X - currently there are no 'radio' provisions to make SDRAngel receive or transmit from that app (WSJT-X). I suppose one could hijack the serial port commands for any radio (let's say, Kenwood) and then look for the PTT command somehow from the app communicating to (presumably) a COM port that's been set up in the app (again, WSJT-X) and sniff it out using a virtual comport app. That would be the way to fire the PTT relay and I would think there's got to be some way of taking the transmit and receive and start/stopping those to get half-duplex. This is where my research is at the time, but I'm not savvy enough with the REST API to make any of this happen right now. I could just as easily do all this in hardware just using the Line-Out function of the PC when WSJT-X wants to go into transmit and have the relay switch to the right port, but it means that the transmit function has to run all the time in SDRAngel and you only use a Upper Sideband modulator and the audio from Line-Out to make the whole thing work...The only clunky thing about it is that the transmit has to run the whole time in 'Angel unless there's a way to shut it off like real half duplex radios do.

...Wish there was a way to do this through 'Angel...It would greatly simplify this whole issue. 

73 de Marty KN0CK


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Edouard Griffiths
 

Hi,

as James mentioned Rest API is the way to go so you can design the piece of software that interfaces with your hardware. Then in turn this software drives SDRangel or is driven by it using the REST API tecjnique. You can do this with any language you like but I would advise to use Python as there are so many libraries available to do pretty much anything you like. I have put some examples in the swagger/sdrangel/examples directory that you can inspire.from. Python requests package is nice to send requests and Python flask to put up a small server to receive requests for the other way round.

Brgds, Edouard.


Re: Does SDRAngel employ a PTT feature, and how does it handle USB relays...?

Michael Durkin
 

I don't have a link for Marty's hardware .. but perhapse an option for
the Ensemble/Softrock Si570 could also be used ..

pe0fko.nl/SR-V9-Si570/

And if i remember .. some one ported the code to Pic32 IC too ...

On 3/13/19, James Dallas <jim.dallas@gmail.com> wrote:
Hi Marty,

I think the API and Reverse API should be useful for this. I've been
tinkering with the API and might be able to find something useful to say
about this with a few hours of experimentation.

The Wiki page for the Reverse API specifically mentions the idea of using
it for hardware control: https://github.com/f4exb/sdrangel/wiki/Reverse-API

Could you forward me an Amazon or eBay link for the USB relay you are
using? Would like to have a common hardware context.



On Wed, Mar 13, 2019 at 11:57 AM Michael Durkin <Kc7noa@gmail.com> wrote:

Ok, i guess were going to haft to get Sid to help a little too ...

Seems , to me ,that were going to use the API..

Does the USB device act like a Serial device or HID ( not that i know
what a HID truly is )

I know that Quisk can use the USB/Si570 USFSDR softrock/ensemble
controller through C++ It is/was USB device ... so i guess that - that
code could be modified to send what the USB/Realy board is looking for
and for the C++ to look for the Device ID of the USB/Realy board
rather than the Si570 controller -- which by the way -- also had a
reduced relay/bandpass filter controll -- i think it had 4 possible
lowpass filters

Not sure ...

On 3/13/19, Marty Wittrock <martywittrock@gmail.com> wrote:
[Edited Message Follows]

Mike,

<crickets>...I am by far the biggest supporter of this software for the
LimeSDR and have been for over a year and it's making me 'simmer' that
I
cannot get an answer to ANY inquiry I post on this forum...What is up
with
that..?

Marty







861 - 880 of 1565