Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: PIN diode T/R switching

PIN diode T/R switching (Re: I "kind of agree" and "kind of disagree".) 14 Aug 2021 12:02 #16

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 339
  • Thank you received: 162
Hi Martin

Again, please, do not get me wrong ... when I am saying "kind of agree and kind of disagree" - I mean it :) and there is nothing hidden behind. I other words what I am saying - I cannot make up my mind at this point of time. Perhaps I have initially chosen wrong words ... and made wrong impression. Believe me, as person, who lived in Praha-4 for almost 10 years, I prefer drink beer, not making wars :)

And CW is, certainly, my absolute dominant mode. Very rare I use DIGI ... and mostly - just for experimenting purposes, because I know Igor (UA3DJY) and love to see and evaluate his programming (and support it as much as I can). I know some people in IOTA, who hate me because I rejecting to use phone in my DXpeditions :), but I think CW is most efficient way for IOTA operations, that is why it is my mode.

Now, back to you idea.
No, I do not see it as unacceptable.
And I am very far from rejecting it.
Actually, what I think it is nice idea ... but too early for SunSDR. (and now I am intentionally entering "fluffy swamp" and may certainly expect Roman and Vasily will slap me). My "only hope" is that Roman is away on leave and by the time he is back, we will come to some clear conclusion, so there will not be need for a slap :)

Let me explain what I mean saying "too early". This has to be combined with answering another sentence of yours that EE "is not interested in the comments of competent customers" (your kind of right and kind of wrong saying that, BTW). Well, "too early" - because, when some ideas are good, they are not ready for EE devices as yet. Not because EE conservative or something. Just because there are other things in a queue. Roman have answered about the size of the queue, saying "not sooner than the end of the next year".

I have read very carefully all your ideas, posted at this forum. Many of them make sense to me. And I understand your thinking - you have posted some ideas and you are expecting reaction from EE ... but there is close to none. Am I right? And the only answer received regarding PIN diodes sounds like "go away", right? :) If so - don't be frustrated. mate. I think your ideas are (mainly) good, some I found questionable, but still good enough. You just need a little bit change in the approach :) Yes, you are right, EE guys are not active HAMs. But they are listening to HAMs. Just, do not expect them to pick up you idea on a fly, then drop everything and start to implement. They can listen - that is what matters (for me at least). Well, sometimes they are acting like a giraffe ... then OK, you just need to take a breath, find the ladder, climb to the head of the giraffe and start - slow and patiently - explain your idea in details. That what I do :)

Another thing (again it is going to be strong statement - but not casus belli!): with all my respect to Ten-Tec and Elecraft, their products are not SDR, not intended to be, whatever they may "define" in their marketing bullshit. FLEX? It was dead almost at the moment of birth. And what I got from EE after 10 years of dealing with them - EE has its own way and own roadmap. Do not ask me where to get this "roadmap" - I am looking for it myself already few years. If I may suggest you try to drop any comparison with other vendors, because there is no currently manufacturer on a market, who we can really compare with. Simply do like that - you need a feature? Well, make sure you have good reasoning, explain rationale (assuming not only from CW perspective, per say) and be ready to fight for your request.

Another thing - you came with your ideas in very rough time. Not "bad time"- precisely rough. Since Jan this year all EE focus is on EDSR3. This version is the key now. We need all ESDR2 features to be ported to ESDR3 and be bug free - this is where all forces are ATM. They have very aggressive timeline ... I would say "too aggressive"... Anyway. Whatever you say to them now - even your idea makes absolute sense - will be dropped into the back of the queue. And if you want your idea to have higher priority in a queue ... well good luck, find a ladder :) But be prepared to face angry users in exchange, because of some people are waiting for the requested features to be release already months and they may not be very happy seeing you feature takes precedence.

Lining up with previous paragraph - you initially have explain PIN diodes rationale well enough. You have EE response, giving you time estimate - congrads (many ideas died in waiting), so mark it as success, I mean it. What is missing now - your own clear understanding how, say mux-demux of PIN-diode flows will fit into current EE PA programming design. Simple, hah?

And, BTW, EE is not Electaft and Ten-Tec, so do not expect them to keep the price in a same level with PIN diodes ON. Those small devils are expensive and EE is feeding from what they sell, so do not expect them wear all price.

Now, I am a bit away from VHF, so forgive my ignorance, but I may not clearly understand what exactly is preventing you now from using VHF LNA with current relay design?

Wow that was bloody long post.
The administrator has disabled public write access.
The following user(s) said Thank You: G3XLG, EA5ML

PIN diode T/R switching 16 Aug 2021 00:57 #17

  • OK1RR
  • OK1RR's Avatar
  • OFFLINE
  • CW forever!
  • Posts: 38
  • Thank you received: 17
Pavel (VK6NX),

we still don't understand each other, everyone is talking about something different.

I don't find anything in your last posting that can be followed up. You declare your assumptions to be a fact, you didn't give the job to verify the production program of possible competitors (Elecraft, Ten-Tec) or the diagrams of their products (not everyone is so paranoid as to hide even basic information). You defend the approach of EE guys without knowing the approach of other companies. The EE approach is fundamentally wrong, because they want to produce for ham radio market, but none of them cooperates with hams (at least no one sufficiently qualified). I can assume that either their (EE) approach will change, they will forget about their “priorities” and the by nobody wanted “queue”, or they will end soon. The manufacturer must adapt to the requirements of the market and they must have someone to formulate, otherwise they will not stand.

Today, SunSDR2 QRP, SunSDR2 PRO and SunSDR2 DX save the EE reputation, but only because their price is set relatively reasonably. The price of accessories (E-coder, tuner AAT-100) do not correspond to what the customer gets for their money and the "flagship" MB1 is absurdly overpriced nonsense (Elecraft K4 costs about half of MB1 Prime). I consider the price of the E-Coder Mini panel to be a provocation that the manufacturer makes a fool of a customer...

The only thing I can tell you is that when I bought the complete K-Line from Elecraft, it was very expensive, but I didn't hesitate for a minute. Since 2013, it has served me excellently, without any problems and continues to serve me. When I put it into operation, I said "how is it possible, they must know me and build a rig tailored to me!". The KPA500 + KAT500 is still in operation and when I pull out the K3 and P3, everything will work like ever before.

Sadly, SunSDR2 DX did not grow on my heart, I still do not trust it and I am disgusted by the approach of EE. I do not believe that it will one day become a rig that meets my expectations 100%. I'll give it another chance - I'll wait for the full version of ESDR3 to be released and try it thoroughly. However, due to my experience with EE and ESDR2, I expect to sell my SunSDR2 at the beginning of next year to a computer-savvy beginner who focuses on local SSB and FT8 and does not ever try to make any DX. So I will wait until the end of this year and I will probably be a "read only", disappointed participant in this forum - further debates clearly do not make sense. Now the ball is in the EE half, so I'll wait for them how they will play.
Last Edit: 16 Aug 2021 01:03 by OK1RR.
The administrator has disabled public write access.
The following user(s) said Thank You: DD5MD

PIN diode T/R switching 16 Aug 2021 07:11 #18

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 339
  • Thank you received: 162
Martin

My personal view that if you want us stop talking about different things and line up, perhaps, you better drop your frustration and come back to the point.

You may start with answering the question - what exactly current relays setup prevents you to do in LNA?

Also as the user I would prefer to see more detailed description from engineer with your experience, apart from just "I need external PIN diode T/R switch". For example, how do you see it implemented? Simple diagram, perhaps?

And what value it will add (apart from price) to not only CW, but other modes? (This is in comparison with current relays setup, of course).

And absolutely top and ideal level of discussion I would expect: if you may express your view, what ways you see to support both versions of hardware - relays (all current line) and PIN (all future lines) - with single Software version.

Yes, I wish to understand all the above. You are not the first person, who came with idea of PIN diodes, but - potentially - you may be first, who will expand the view to more understandable level.

The rest of my post, I believe, is more personal discussion between you and me and potentially should go in private, hence I hide it under spoiler.

Warning: Spoiler! [ Click to expand ]
Last Edit: 16 Aug 2021 07:13 by VK6NX.
The administrator has disabled public write access.
The following user(s) said Thank You: UA4FX

PIN diode T/R switching 17 Aug 2021 17:17 #19

  • OK1RR
  • OK1RR's Avatar
  • OFFLINE
  • CW forever!
  • Posts: 38
  • Thank you received: 17
The purpose of the whole debate on T/R switching is to show that switching using PIN diodes solves absolutely nothing (except the annoying noise caused by the relay, possibly also the lifetime of a relay). The problem is much deeper and more complex, with two main aspects to emphasize:

1) receiver recovery time - makes impossible to listen between characters/elements.
2) transmitter actuation time - causes a shortening (I call it "biting") of the first element of the transmitted element so, that EA becomes A, JA becomes OA and my call OK1RR may sound like WK1RR. This returns a 50-year-old problem from the era of transceiver beginnings. As then, so today there is only one cause - ignoring or at least neglecting CW as a mode.

It might seem like I'm extremely biased towards CW and QSK. However, the exact opposite is true. It is clear to any good engineer that this is not telegraphy (CW) at all, but a fundamental system problem of latencies and delays. CW only works as a touchstone here - the essence of the problem is that if the CW (including QSK) is OK, there can be no problems with timing (delays, latencies) elsewhere and the situation will be clearer and easier to manage throughout the transceiver. Everyone will benefit from the final solution of timing problems, including those users who have no idea what telegraphy is.
Last Edit: 17 Aug 2021 17:19 by OK1RR. Reason: typos
The administrator has disabled public write access.
The following user(s) said Thank You: EI9HEB

PIN diode T/R switching 18 Aug 2021 04:35 #20

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 339
  • Thank you received: 162
Martin,

People are connecting to SunSDR and using daily wide range of keyers - pure hardware, or HW/SW devices, or pure program-based. People were winning contests with SunSDR in hand in CW only mode. With all my ... "complicated" (this would be proper word) ... view on what EE does with feature set expansion, saying, that they are "ignoring or at least neglecting CW as a mode", I think, would be completely unfair.

Do they have fully finished CW feature set and does everything work properly? Of course not. There is fair amount of stuff to be done.

I personally never had recovery time issue, because in my typical CW operations I usually not passing above 30 WPM. However I can imagine the scenario with very high speed manual keying, when you may hit current threshold - what you called transmitter actuation time. Specifically with the setup introducing additional delays. Please excuse me asking, perhaps, stupid question, did you actually spoken about the issue with EE support? Did you demonstrate them under what conditions it occurs? It cannot be you just relying on forum posts only...

Receiver recovery time - this, as per my understanding, would affect semi break-in in certain conditions. Again, since 2013 I personally did not hit this issue (which does not mean it not exists). But if you are after reducing recovery time, I would start with asking Roman what is the release time for current relays (doubt it is more than 18 ms) and what add-on on top of that actually introduced by overlaying software. This would give me a figure to start measuring against. It might be quite possible to reduce recovery time via programing. You said you have the measurements, but - again - have EE seen those?

The final thing I would do (if I have kind of issues, you've mentioned) - I would ask Roman what is in current queue for CW implementation and make sure my request is in. Then I, certainly, ask "when". But this is me. You may choose whatever approach.

Regarding fundamental problem of latencies and delays - thank you, we all, including EE, are very well aware of existence. However, what surprises me - you seems to be competent enough to define this problem as fundamental - and you still think PIN diodes are the panacea? Really? Excuse me, my view on that in particular: trying to fix latencies and delays with PIN diodes sounds to me very mechanical "hammer" approach, and I much doubt the result will meet the expectation. Because for the SDR world the problem of latencies and delays is a) the add-on on top of physical, and b) starts with difference of operation systems and the way MS, Mac and Linux are handling multimedia traffic flows. Qt6, with all its beauty, has only partial answer, but I have a confidence, that EE understands that very well. Hence, I prefer to let them do their job and do my best to test the alphas.

Just fair bit of warning, Martin. Do not expect ESDR3 will magically fix actuation and recovery, just because you have mentioned those on forum. Measure, then align measurements with standards (or best practices), report and set your expectation - that is how we, users, ensure EE is fixing things. If this sounds too boring, then you better rely on magic of Ten-Tec and Elecraft.
The administrator has disabled public write access.
The following user(s) said Thank You: UA4FX
  • Page:
  • 1
  • 2
Time to create page: 0.115 seconds