Title: Antennenrelais bei CW zu träge??
Post by: dl7pf on 25. January 2018, 19:41:28
Hallo,
bei meinem mcHF habe ich festgestellt (v0.4, Antennenumschaltung mit Relais), dass bei CW (Keyer Mode IAM B und Delay 100 ms) beim ersten Zeichen der erste Punkt immer fehlt bzw. der Strich etwas verkürzt wird. Beim Tasten eines v höre ich im Mithörton das v, sehe aber auf dem Display eine 4.
Gib es die Möglichkeit das zu korrigieren?
73
Wolf |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 05:10:59
Reduziere den Delay auf "0".
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: S53DZ on 26. January 2018, 06:28:03
Hallo Wolf,
Yes, because the dot length at e.g. CW speed 25 WPM is 50 ms. At CW weighting = 1.
73 Bojan |
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 07:23:28
... the dot length at e.g. CW speed 25 WPM is 50 ms. At CW weighting = 1.
|
|
Hello,
typically relay contact closing time is around 5 ms at best, as we know from QSK experiments. Even if it's a bit worse the first dot would be a bit shorter but still there at 25 wpm, and speeds up to 35wpm should be possible to hear first dot safely (but not nicely).
But Wolf seems to state the first dot missing? Or is this a QRQ disussion?
73
Gerd |
Title: Re:Antennenrelais bei CW zu träge??
Post by: S53DZ on 26. January 2018, 08:16:29
My observation is this:
if the TX delay is set to be at 100 ms, then the first RF signal you get out of mcHF using Iambic B would occur after 100 + 5 ms.
Assuming CW letter S:
At 25 WPM the dot is 50 ms and RF out would be at the beginning of the second dot.
At 35 WPM (QRQ) however, the dot is 35 ms and RF out would be exactly at the end of the second dot.
It is just a comment about why you don't have output of the first dot when you use "long" TX delay. And I assume there is an additional delay aspect of CW machine and generating DSP TX output signal.
73 Bojan
|
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 10:02:18
Bojan,
if that is the case: isn't that a bug that needs to be raised at Github?
The concept of delaying CW and still cutting the first dit/dash is new to me...
With delay set the Iambic input should stored and output with delay also, not just discarded.
I currently just have the OVI40 UI board, no RF board - so cannot replicate / test for now, sorry.
Might be interesting for the developers to check how others implement this, e.g. in the Microham USB devicerouter SW (manual to be found on microham site).
Gerd.
|
Title: Re:Antennenrelais bei CW zu träge??
Post by: DD4WH on 26. January 2018, 10:35:12
Maybe we had this discussion already?
And I remember Danilo worked intensively on this:
https://github.com/df8oe/UHSDR/issues/1011
https://github.com/df8oe/UHSDR/issues/669 |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 11:07:13
Yes. Because of we never know WHEN the first CW input signal comes (maybe during an audio interrupt cycle) we first must end this. UHSDR is NOT a standalone CW keyer software - it is a standalone SDR software with CW capabilities.... Getting rid of this first delay is not a simple task and maybe there must be huge changings in complete timing. So noone has started that (and I by myself will never start that). If you reagrd straight key things will become much more complicated again.
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DJ3FV on 26. January 2018, 12:17:01
Wolf,
darf ich denn mal fragen welche Firmware Version du verwendest?
73
Uwe |
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 12:32:07
Referring to Github Issue 1011 https://github.com/df8oe/UHSDR/issues/1011 (https://github.com/df8oe/UHSDR/issues/1011)
In issue 1011 DB4PLE commented on Aug 21, 2017:
[...] we had about 23ms delay going from RX to TX in CW with straight key. There may be additional delay before we start processing the first character since we have to wait for the main UI to decide to go to TX. This delay depends a) interrupt load (filtering & DSP use) and the waterfall / scope settings. Please disable waterfall or scope ("increasing" speed to 0 will disable scope or waterfall) and test if this provides improvements. [...]
From CW operator perspective (I only do CW):
- To set the relay hold time "semi break-in" long is not an option. Good CW QSOs are interactive and not monologues
- Waterfall and Spectrum are not used / usefull during CW QSO. Would be great to have waterfall & spectrum stop automatically (for a configurable time?) every time I touch paddle or straight key
- Delay between touching the paddle / key and the actual sending of dit/dashes is no problem, as the sidetone is real-time with paddle/key actions. Any noticeable dela betweeen touching paddle/straight key and the side tone will make CW ops loose their mind.
Possible implementation:
1. When touching straight key / paddle:
1.a High prio interrupt starts side-tone, even if UHSDR still in receive
1.b straight key / paddle input is stored
1.c Waterfall and Spectrum switched off for pre-configurable time (300 ms?)
2. When UHSDR is in TX mode (result of touching paddle / key):
2.a stored CW input (1.b) is sent
2.b any CW input while 2.a is stored, then sent
Comment: This will result in a short delay at end of sending (lag). So be it. Lag upto 100ms absolutely ok (similar lag used for PA PTT even in tight contest QSOs)
Could this be a simple solution to this issue?
Apologies for the text length - CW matters to me a lot. ;-)
BR
Gerd.
|
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 12:50:46
Gerd,
due to many different tasks a SDR has to do I think it is not the best decision to take such a radio as QRQ CW device. In this case a radio, conventionel built is the best solution. In QRQ timing will grow into regions where it conflicts with other tasks. Not only UI - but audio interrupts e.g.
"High Prio Interrupt" does not mean to kill the running task unconditionately. Sometimes there are tasks to end before a new interrupt can be placed. This can be some ms of time if you come up in a unconfortable moment.
If you are working CW in "standard speeds" UHSDR already is quite good. Better when using keyer than straight key...
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: S53DZ on 26. January 2018, 12:52:23
Hi,
I understand the UHSDR implementation of TX delay is such that this is the time between setting PTT line and start of actual RF output. This is to cover for the transition time from RX to TX (relays, PA, trv rx input) to prevent damage of circuits.
To be clear here, I was just trying to explain the pure theory facts about CW timing.
I have no troubles with that since I have my TX delay set at 0 ms and I am using mcHF alone. So, I really have to count only a relay switch time (few ms).
This setting is good for all modes!
But if you have to set TX delay to > 0 ms, then you have to count in possible loss of data in CW and digital modes. I suppose there is no intention or need to introduce any kind of time delay line. And also no need for a new github issue!
These are my thoughts.
73 Bojan |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 13:05:31
Hi Bojan
I agree. My maximum CW speed is widely under QRQ. But I never have had trouble when doing CW (delay set to "0").
There are two delays:
1) technical ones (relay switching time, generating BIAS for PA (charge time of capacitors) e.g.
2) delay because of MCU
1) would be very, very small and I think will not impact QRQ at all.
But 2) does. There are already high priority interrupts for audio chain running which must be left cleanly, you must set another TX frequency and some other little things without TXing would not work. Each only eats some percents of milliseconds, but many of them may impact QRQ operating. If you increase startup time in an "unclean manner" you possibly left the first milliseconds when going again to RX because you first must initialize all new (because you don't know if you left it clean).
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 15:20:54
Andreas,
firstly please understand: I am not pushing for a certain feature implementation. Other topics having higher prio - fine.
Let's put the concept discussion at rest until RF board is released, and many current open tasks aore in a better state.
But - please - let's not say this is not an issue.
Just to give you my perspective as an active CW op:
- 25 wpm is a standard CW speed that UHSDR / OVI40 needs to master - no restrictions
- 25 .. 40 wpm ist "faster normal operation", but by no means QRQ.
- 40 wpm and more is QRQ, few people use it, may be not be worth the effort to implement and yes, timing i getting tight.
The 25wpm / 40wpm statements can be verified by a look at RBN (reverse beacon network) raw data.
As to straight key: Needs to work up to 25wpm, better more (remember Bugs / Vibroplex?)
Every good CW op will slow down as needed for a slower OM. But having to slow down because of the rig - no no no ;-)
"Conventional radios" also tend to have this problem BTW. Just a question how much attention the developers puts into this.
Let's have this discussion again when the RF-Boards are released and many other now urgent open tasks are closed?
BR
Gerd |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 16:06:23
Hi Gerd,
of course we can discuss later (or now - I think Danilo, Frank and Michael are reading here, too). But again: I do not think that it is solvable without a very, very big restructuring and possible lost of features, which give UHSDR-radios its "high standard level". And maybe it is not solvable, too. MCU has a rated horse power and it can be that we cannot go to TX using the speed you need for >25WPM.
BTW:
For my skill QRQ starts at 25WPM ::) Of course I know that some are capable of hearing and TXing much faster. But that's "another universe" - for me and for standalone SDR radios with a graphical interface...
If it is an issue or not is dependent from the site of view, too. For a QRQ user of course it is an issue. But if there is no way to get rid of it using the existing chain of IQ-audio-streaming via I2S, digital filtering, digital demodulating, pushing again via I2S to audio codec back - I will not call it an issue. If it is so, it is the "technical edge" of the system in this point...
But I like to hear Danilo and the others, too. Talking we can at every stage. But if that means completely new beginning of firmware programming the question will be: who will do that? And are most users happy with a rig that has no waterfall or scope, no selectable bandwidths, of course no CAT (that is an interrupt, too), of course no DSP (notch, NR, NB), only a 7-segment-LCD for frequency but can go CW in QRQ?
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: dl7pf on 26. January 2018, 16:20:29
Liebe OMs,
das ist ja schon eine sehr ausführliche Diskussion geworden. Danke für die vielen ausführlichen Kommentare. Ich sehe nun, dass es nicht nur bei meinem Gerät das Problem gibt.
Da ich, wenn ich CW mache, sehr langsam unterwegs bin, also z.B. bei 16 wpm, stelle ich Delay mindestens auf 50 oder mehr, damit das Relais nicht zwischen den Zeichen schon wieder abfällt ;) . Aber auch beim Delay 0 schafft es kein E auch nur teilweise an die Antenne, was ja nach den dargestellten Berechnungen eigentlich der Fall sein sollte. An meiner Hardware sollte es nicht liegen. Was kann man da falsch machen?
Zzt. habe ich FW D2.6.0 installiert. Vielleicht gibt es ja in künftigen Updates doch mal eine Lösung.
73
Wolf |
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 16:27:14
Ok Andreas.
Just to clarify: I am saying that during CW QSO waterfall / spectrum is not needed. During CW QSO I listen (or may read CW decoder), but can do without waterfall / spectrum
The statement in Github issue 1011 was that switching off spectrum / waterfall will improve the situation. So I propose to have spectrum / waterfall in CW receive (of course!) but when sending CW to have it stopped automatically for the time I am sending CW.
When paddle is released (plus delay) waterfall/spektrum start again, automatically.
Gruß
Gerd. |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DD4WH on 26. January 2018, 16:37:50
I guess to really solve the problem, we need a completely new audio handling for CW in the UHSDR. This includes not only fast TX signal shaping/filtering, but also codec switching etc.
Any volunteers? ;-)
Frank DD4WH |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 16:40:25
Gerd,
Danilo GUESSES and wants testing *if switching off waterfall and/or spectrum helps*. But until now nobody has confirmed that.
Switching off wf/scope during TX does not help. You must switch it off at RX!!! Data traffic to LCD must be eliminated (and I am not sure, that will change anything). The problem is the time we need from any time slot in RX to go to TX. Nobody knows what firmware is executing when you press the key or activate the paddle. That can be at the beginning of an audio interrupt, at the beginning of a LCD transfer and so on.
Please test and report if switching off will change anything - reports are highly welcome!
I think the biggest problem is the audio interrupt itself. Just a guess. And that would be very bad.
EDIT:
I think nobody knows audio processing scheme better than Frank. And he has the same feeling as me. It will be possible - but the price is a very high one.
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DB4PLE on 26. January 2018, 16:55:25
Hi,
without too much details: If we want to have less delay in RX to TX and a more deterministic delay, a serious rewrite of very critical portions of the software is required. It needs a lot of thought to be done otherwise we will run in high instability (read crash) risk. Trust me on this.
Some more on this:
Moving the RX/TX switching into an interrupt is of course possible but needs to be synchronized with a lot of other activities since everywhere in the code (display, button handling, audio processing) we assume that we don't switch rx/tx mode when we run a function. Switching RX/TX inside an interrupt would break this assumption and we would have to first identify and then rewrite the code which does have a problem with that. And identify means essentially to look into ALL source code we have.
73
Danilo
|
Title: perfect CW hardware for high speeds (> 20WPM)
Post by: DF8OE on 26. January 2018, 16:58:27
My idea for OVI40-II:
Adding new hardware. We do need a sine wave generator which produces 0/90/180/270° sine wave which is switched directly (!!) to the IQ Modulator. Of course LO must be adjusted according to choosen RX frequency before. But transferring a new frequency to LO should be fast (I do not know the time PLL needs to snap but I think it will be some us). We will need a second MCU to do CW stuff "keyers". That part of code is very simple and will fit to STM32F100. Because this MCU in RX will do nothing else than waiting for a CW TX command (straight key or keyer) there will be no impacting delay.
If we go this way, we do not need to stop tasks of main MCU unclean, we can leave both codecs in the state they are and tone generation of sine ave for CW can run continuosly.
And, believe me:
I think adding such hardware and changing layout of UI PCB is an quite easy task than rewriting complete firmware.
Edit:
Hmmmmmm.... I see that connectors for CW are located on RF PCB.... So it would be a great idea to add a header where we can cut the old keyer routes to UI PCB and possibly fit a PCB whith such special CW hardware at a later state of RF PCB design. As I already told it is modularized. I know what kind of signals we will need / must cut, give it some of the (thank god) free GPIOs to it and later users who want to use OVI40 intensively for CW can add this module...
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DB4PLE on 26. January 2018, 17:10:52
Hi Andreas,
that additional hardware would not at all solve the problem I described. Throwing more hardware to fix a software design issue is in general not a good idea and also not in this particular case. That is "rumfuschen".
We should rather fix the software. And before we go to rewrite the whole thing, we should figure out what is going on. That the keyer sends out a too short first dot is something we can look at and fix most likely relatively easy. We can't fix the somewhat indeterministic delay though, we can only try to reduce the delay (unless we do the full software makeover as discussed above).
73
Danilo
|
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 17:19:52
Hi Danilo,
if the work you have to do for fixing the problem is very intensive and will take long time (and maybe will not work at all using the given hardware) it is always a serious way to add hardware which solves the problem.
My idea was only a very early "pre-alpha-stage-idea". But if we can cut all lines which are needed for CW TXing by hardware switches, generate the necessary signals using a second MCU and leaving the rest untouched that will do the job and if something does the job it is no "rumpfuschen" in my eyes.
I do have concrete schematics in my head which lines are needed - it is just a handful.
And I by myself never would need that - because I am not working in CW faster than 20WPM and use a keyer for that speed. Using straight key I am able to TX with 15...17WPM - that speed works flawlessly with mcHF/OVI40/UHSDR. This is just a tribute to the CW enthusiasts - and there are reasonable groups of persons who would like that.
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: df9ts on 26. January 2018, 17:45:09
Andreas,
sounds great. If you think about CW & Rf board please consider that - depending on PA design and filtering - for CW the PA may not have to be to be linear. If PA non-linear biased for CW it may consume less DC power. Remember Frank's "power efficiency" discussion from yesterday. Again this is just a thought, no feature request.
Danillo,
proposal was:
- make audio sidetone generator deterministic (whenever CW contact closed the sidetone is generated in "realtime")
- CW Contact closure / open is written into buffer with time stamps, estimate resolution of timestamp should be 5 ms (guessing here)
- This buffer is used since as the experts explain UHSDR switches from RX to TX in a non-determenistic way, certain ISR need finishing.
In short: sidtone audio output deterministic, actually sending lags behind, delay non-determenistic. From previous discussion I understand delay 30..50 ms - this is no problem.
Dependency: Since CW is sent from buffer the UHSDR needs to empty CW TX buffer before switching to RX (assumed 50 ms) and another non-determenistic delay to switch from TX to RX needs to be waited for (another 30..50 ms worst case). Total less than 100 ms, not a problem
BR
Gerd.
|
Title: Re:Antennenrelais bei CW zu träge??
Post by: DF8OE on 26. January 2018, 18:06:54
Hi Gerd,
of course I know PA must not be linear in CW. But the PA design I use consists of a double LDMOS circuit. These circuits have very high dependency between BIAS and amplification. So I must add a new stage (I call it "CW C operation) where BIAS is constantly on but very low. No problem because of BIAS is measured actively and can be readout via software. I use 20A hall element I2C current sensors on each LDMOS and BIAS can be set to every mA count you can imagine. I also will use this current measuremment for security circuit of PA if there is antenna misalignment or other damage.
I already do have a complete ("basement") additional hardware in my thoughts. Very good that I always develp electronics "in my brain" - no schematics drawn. So it is easy to add before alpha stage. Do not misunderstand: I only will add the neccessary headers to RF board. There will be some tracks that must be cut later if you want to use "CW addon board". Actually I only must add some tracks, some headers and some 0R resistors.
Shaping of edges of CW signal can be made via software ("anti-click").
vy 73
Andreas |
Title: Re:Antennenrelais bei CW zu träge??
Post by: DL3AAA on 29. January 2018, 14:48:36
Ich habe heute mit einem befreundetem OM auf 10 Mhz CW mit 30 WPM getestet.
Er hat mir auf Nachfrage die Aussendung als in Ordnung, ohne fehlende Zeichen/ "Zeichenanteile" am Anfang der Aussendung, bestätigt.
OVI40 v1.07
Sendeumschaltung mit Relais
TX/RX Delay 10msec
Power 10 Watt
FW D2.7.66
Da ich CW sonst nur mit max. 22/23 WPM mache, habe ich auf Grund der Diskussion, dieses mal mit meiner Hardware getestet.
73
Dietrich |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|