Welcome, Guest
Username: Password: Remember me

TOPIC: tciscan plugin

tciscan plugin 16 Apr 2020 07:15 #1

  • LA3QMA
  • LA3QMA's Avatar
  • OFFLINE
  • Posts: 26
  • Thank you received: 22
I need feedback on this tool: github.com/LA3QMA/tciscan

1. Have you tested the tool? If yes on HF and/or VHF, wich tranceiver?
2. For what operating system? windows/linux/mac/raspberry 32 or 64bit?

I'm asking this to find out how much time i should use on the plugin.

For now i can make a workaround so that repeater split and/or ctcss can be stored in the ESDR2 fileformat. You then have to add some data in the comment field. Then wait for EE to release an version where this is stored automatically. But this is "wasted time" as i have to reprogram when a new release of ESDR2 are available.

I could change the program to have a separate memory list but i personaly want to use ESDR2 internal.

So i'm probably going to wait for a release when the transverter function is implemented. Then the fileformat for the memory has implemented split/ctcss and maybe a tag for "lock out".
The administrator has disabled public write access.
The following user(s) said Thank You: KI5FTY

tciscan plugin 17 Apr 2020 23:57 #2

  • KI5FTY
  • KI5FTY's Avatar
  • OFFLINE
  • Posts: 31
  • Thank you received: 13
Yes very nice tool but it has little use to me without repeater offsets and tone. Maybe you and ESDR2 programmers can agree on a file format so you can implement and not rewrite the code. I would be glad to enter the information via a text editor.
Lou ki5fty
The administrator has disabled public write access.
The following user(s) said Thank You: LA3QMA

tciscan plugin 19 Apr 2020 17:01 #3

  • LA3QMA
  • LA3QMA's Avatar
  • OFFLINE
  • Posts: 26
  • Thank you received: 22
I could probably add a tag to use a csv file with the options for ctcss, repeater shift etc.

Not sure how the transverter data is going to be saved internally but i'll send an e-mail to EE and ask if they have made any preliminary file format for the repeater shift, ctcss, transverter etc.

Since different regions have different split etc i suppose that it's better to store the offset and specify if it should be + or -.
What about cross band? Or is it better to just store the input and output frequency?
The administrator has disabled public write access.

tciscan plugin 26 Apr 2020 22:52 #4

  • KI5FTY
  • KI5FTY's Avatar
  • OFFLINE
  • Posts: 31
  • Thank you received: 13
Explicitly storing the frequency is probably the right thing to do since cross band will work will easily enable different offsets for other regions. Then it eventually could be the role of the ui to look up offset and store the explicit frequencies. Also less compute at scan time.
Lou ki5fty
The administrator has disabled public write access.

tciscan plugin 03 May 2020 18:40 #5

  • LA3QMA
  • LA3QMA's Avatar
  • OFFLINE
  • Posts: 26
  • Thank you received: 22
tnx. I have started on a version using an external memory file.

73 de LA3QMA
The administrator has disabled public write access.
Time to create page: 0.145 seconds