¿ªÔÆÌåÓý

Date

toroid on USB line for CAT control #ubitx

 

Ever since I have been using cat control for FT8 on the CEC firmware. I have been having intermittent lockups involving the usb port. I have a work around it seems that I must have been getting some rf back into the computer.?


Re: RF power chain mods and improvements..

 

Allison,

Getting the analog stuff to where it is flat from 3.5-30mhz is preferred if the mods are easy,
we much appreciate your efforts in this in this regard.

However, gain per band can be done with zero additional hardware,
a rare case of being very very cheap:
? ??/g/BITX20/message/50217
? ??/g/BITX20/message/50184
The KD8CEC software already has this feature fully implemented.

I am curious if you have ruled this method out for some reason.
You'd think it might mangle the audio frequency response some,
but I can't hear anything other than reduced amplitude as I take it down the skirt.
That's a fairly broad filter.

Jerry, KE7ER



On Thu, May 24, 2018 at 05:25 am, ajparent1/KB1GMX wrote:

Gain per band has been widely used and work save for its rarely cheap and tends
to add a lot of circuitry.


Re: spurious signals on FT8 #ubitx

 

A few things I found with my Bitx40 and Ubitx. Turn the drive down in the rig itself for digi modes, also check for any kind of ground looping. When I was 1st running my Bitx40 I ran r136 at half of what is normal after getting reports I was txing in a few spots at once. This was also in combination with a ground loop from my pc, after moving r136 it was reduced and again after using a laptop it was completely gone. I found the audio was over driving the radio even set very low and caused a lot of issues.

?Another thing to make sure is a DC blocking cap on the mic line so as not to mess with the computer or the interface if you use one.

73
--
David

?N8DAH


Re: Nextion Display

 

Jack,
? Thanks for that info, I will have to try that. I am still debating the analog style vs. the bar graph. I think analog looks nice if done right and I am going to give it my best effort but if all fails I might just use a real analog meter instead. I am really enjoying the challenges and trying to find solutions.

Stephanus, K6NG


Re: CW Transmit Frequency VS Sidetone setting #radiuno #ubitx #ubitxcw #firmware

 

On Thu, May 24, 2018 at 02:07 am, Tom, wb6b wrote:

Call me old fashioned, but shouldn't the radio transmit on the displayed frequency and any frequency offset to create the tone for CW be done as a receive frequency shift, such as RIT? Maybe the preference has changed.
You are absolutely right. We had similar discussions for the Raduino sketch for?BitX40 at the time.
During TX the frequency shouldn't be shifted - the actual TX frequency should be?equal to?the frequency as shown on the display.
During RX, the frequency needs to be shifted to the same amount as the side tone frequency setting.

73 Allard PE1NWL


Re: Nextion Display

Jack Purdum
 

Initially, I had an analog S-meter on the JackAl board, but changed to a bar meter, mainly because I was running out of nano-acres. You can make the meter look "less jerky" if, when you compare the new position with the old position, you divide that difference by some constant (e.g., 5) and do the erase-redraw in 5 steps rather than in one jump. Sometimes it will look better if you throw in a small delay (e.g., perhaps 20-30 ms) between each redraw, too. That way, the needle "slides" to the new position rather than jump to it.

Jack, W8TEE

On Thursday, May 24, 2018, 8:15:20 AM EDT, stephanus1@... <stephanus1@...> wrote:


I have also started to play with my 3.5 inch display and so far i am good with the results. The only part I am not sure about is how to do the serial coms from the raduino to the display. The attaced video is a work in progress.
More info is always appreciated.?

Stephanus
K6NG?


Re: RF power chain mods and improvements..

 

HI Rahul,

Gain per band has been widely used and work save for its rarely cheap and tends
to add a lot of circuitry.

Equalizers are well known too.? For the astute may notice I'm taking that path.
To do that you need enough gain across the bandwidth and a way to tamp it down
so its flat.? You can't do that with 3904s as they lack the gain at 30mhz.? Fix that
and feedback with contouring can then work.? ?As is we have a default negative
contour as the over all gain diminishes with frequency due to transistors used
in the transmitter stages.? ?Fix that and the performance improves greatly.

The trick if any is KISS, keeping it simple and supportable.

Allison


Re: Nextion Display

 

I have also started to play with my 3.5 inch display and so far i am good with the results. The only part I am not sure about is how to do the serial coms from the raduino to the display. The attaced video is a work in progress.
More info is always appreciated.?

Stephanus
K6NG?


Re: CW Transmit Frequency VS Sidetone setting #radiuno #ubitx #ubitxcw #firmware

Jack Purdum
 

This seemed odd to me, too, but since I'm not an EE type, I simply assumed this was the way it's done and jumped on the bandwagon. I worried about two hams chasing each other right out of the band, but never had problems making contacts.

Jack, W8TEE

On Thursday, May 24, 2018, 5:07:33 AM EDT, Tom, wb6b <wb6b@...> wrote:


Hi,

I was recently puzzled about why my transmit frequency seemed to be about 1khz low on 80M. I was doing what seemed natural, using the CW key to key up the transmitter into a dummy load and check the signal on another receiver. The frequency of the uBITX when in the receive mode was accurate.?

I noticed this on the original factory firmware, but switched to the CEC because of the additional features it provides, and so I could experiment with more parameters to adjust vs the transmit frequency shift. What I discovered is, as with the factory firmware, the transmit frequency is shifted. With the CEC firmware I was able to determine the transmit frequency shifts by the amount of the sidetone setting. Varying the sidetone setting lowered or raised (depending on the LSB, USB, CWU, CWL setting) the transmit frequency by the same amount. This is only when keying the transmitter with the CW key. PTT for SSB does not seem to be shifted.

Call me old fashioned, but shouldn't the radio transmit on the displayed frequency and any frequency offset to create the tone for CW be done as a receive frequency shift, such as RIT? Maybe the preference has changed.

The CEC firmware has defined settings for the SSB and CW modes, so setting a receive offset in the CW modes would seem like the solution. On the original factory software the solution is not as clear.

Tom, wb6b


Re: W8TEE vft/tft questions

Jack Purdum
 

I think there is a library that accounts for this, but I don't remember which on it is. A little Google time on the Arduino programming Forum might pay dividends.

Jack, W8TEE

On Thursday, May 24, 2018, 1:11:15 AM EDT, Arv Evans <arvid.evans@...> wrote:


There are some encoders that do put out 4 pulses (two sets of A & B pulses) per detent.?
This has been discussed before.? The fix was to make the code swallow two pulses and
use the other 2 pulses.?

Arv
_._


On Wed, May 23, 2018 at 9:00 PM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:
It appears that your encoder sends out 4 pulses on each detent. I'm not where I can test the code, but try something like this:

void SetEncoderDirection() {
??? int count = 0;

? ? encoderDirection = 0;
????
????newPosition = rotary.read();
??? if (newPosition == 0)
??????? return;

?? while (count < 4) {??????? // Ignore 3 readings

? ????newPosition = rotary.read();
?? ?? if (newPosition != oldPosition) {
? ? ? ?? if (newPosition > oldPosition)
? ? ?????? encoderDirection = 1;
? ?????? else
? ? ????? encoderDirection = -1;
? ????? oldPosition = newPosition;
???? }
??? count++;
}

The idea is to throw away all but the last direction read. Like I said, you'll need to play with it. Also, it will be easier to read your debug code if you don't put things on a new line. Use something like:

#ifdef DEBUG
?if (newPosition != oldPosition) {
? ? ?Serial.print("In SetEncoderDirection old = " );
???? Serial.print(oldPosition);???? ?????????????????????????????? ??????// No newline here
? ?? Serial.print("?? new = " );
???? Serial.println(newPosition);
?}???????????????????????????? ??????????????????????????? // Move this one from here....
#endif

If DEBUG is #defined at the top of the file, the debug statements are compiled into the sketch. Comment the #define DEBUG line, and they are no long in the executable, but still can be turned on again if need be.

Jack, W8TEE

On Wednesday, May 23, 2018, 6:13:07 PM EDT, tom.mccobb@... <tom.mccobb@...> wrote:


Hi Jack, thanks for answering.

I have been watching the debug code you mentioned, and the output has changed since things went south.

I added some Serial.print statements of my own.? After watching the debug output for a while, I wanted to know what was going on in SetEncoderDirection:

void SetEncoderDirection() {
? encoderDirection = 0;
? newPosition = rotary.read();
?if (newPosition != oldPosition) {
? ? ?Serial.print("Old: " );
? Serial.println(oldPosition);
? ?Serial.print("New: " );
? Serial.println(newPosition);
?}???????????????????????????? ??????????????????????????? // Move this one from here....
? if (newPosition != oldPosition) {
? ? if (newPosition > oldPosition)
? ? ? encoderDirection = 1;
? ? else
? ? ? encoderDirection = -1;
? ? oldPosition = newPosition;
? }
}

...and also here, at the top of your debug block:

#ifdef DEBUG?
?Serial.print("Direction: " );
? Serial.println( encoderDirection);? ? ? ? ?
Serial.print("Examine Fast Tune: Start = ");? ? ? ? // May be useful for setting Fast Tune rate
Serial.print(fasttuneStart);
Serial.print("? ?end = ");
Serial.print(fasttuneEnd);
Serial.print("? diff = ");
Serial.println(fasttuneEnd - fasttuneStart);
#endif?

With this in place, I turned the encoder one detent stop, and you see that SetEncoderDirection was called three times.? I kept doing this, slowly, and you can see from the serial monitor output below that even though I am turning the encoder int he same direction, the encoderDirection is variously 1 and -1.? Every 3rd turn the frequency is just not updated at all, but with the vacillating encoderDirection, the freq. goes up 100Hz and down 100Hz.? I thought maybe a bad solder connection was causing a kind of "echo" in the circuit, so I re-flowed the solder to pins 18, 19 and 20.? I have tried a couple of encoders with the debounce caps installed (but who knows, maybe I have a drawer full of bad ones).? I was reading your followup article on encoders and when I got to the end where you suggest always to look for the last thing you think might be wrong, I even changed the connection wires.? Last thing? that I can think of is to swap out the Arduino mini, which I will get to in a day or so (ugh, all those header pins to solder).? If you can suggest anything else, let me know.? Serial output follows:

First turn here:
Old: -1
New: 0
Old: 0
New: -1
Old: -1
New: 0
Direction: 1
Examine Fast Tune: Start = 3324? ?end = 11398? diff = 8074
Old: 0
New: -1
Old: -1
New: 0
Old: 0
New: -1
Direction: -1
Examine Fast Tune: Start = 11539? ?end = 31281? diff = 19742
Old: -1
New: 0
Old: 0
New: -1
Old: -1
New: 0
Direction: 1
Examine Fast Tune: Start = 31422? ?end = 40482? diff = 9060
Old: 0
New: -1
Old: -1
New: 0
Old: 0
New: -1
Direction: -1
Examine Fast Tune: Start = 40623? ?end = 48869? diff = 8246
Old: -1
New: 0



Re: RF power chain mods and improvements..

Rahul Srivastava
 

Alison,

You have put in some remarkable efforts in gain equalisation and I fully realise it is not a trivial task. Over years I have seen many application's struggle with this. 2 methods that come to mind I feel worth giving a try are as follows:

1) Gain Per Band: In early days of SDR 1000 this was a big problem and later with HPSDR. HPSDR version of PowerSDR incorporated? gain per band setting for a flat power output. This can be easily implemented in Dr Lee's software by incorporating filter skirt attenuation in Tx path.

2) Brute Analog Way: Now this is some what very unconventional. Old analog Cable TV system used a a filter called Slope Equaliser this had a characteristic reverse of cable loss ie least loss at max freq and max at lowest freq. These units came in 2 flavors fixed and variable, fixed were for certain length of cable with know attenuation slope and variable to set the slope as desired. MCL has some expensive solutions also
Some theory like this:? ?


I feel given the limitations of current components we run the whole linear chain at full throttle on 28 and incorporate such a solution in software or in hardware a passive LC slope equalisation network network between drive control preset and PA chain. Set the target for uBits as 5W flat across full HF.

Just some ideas after all Bitx's are experimenters platform...


CW Transmit Frequency VS Sidetone setting #radiuno #ubitx #ubitxcw #firmware

 

Hi,

I was recently puzzled about why my transmit frequency seemed to be about 1khz low on 80M. I was doing what seemed natural, using the CW key to key up the transmitter into a dummy load and check the signal on another receiver. The frequency of the uBITX when in the receive mode was accurate.?

I noticed this on the original factory firmware, but switched to the CEC because of the additional features it provides, and so I could experiment with more parameters to adjust vs the transmit frequency shift. What I discovered is, as with the factory firmware, the transmit frequency is shifted. With the CEC firmware I was able to determine the transmit frequency shifts by the amount of the sidetone setting. Varying the sidetone setting lowered or raised (depending on the LSB, USB, CWU, CWL setting) the transmit frequency by the same amount. This is only when keying the transmitter with the CW key. PTT for SSB does not seem to be shifted.

Call me old fashioned, but shouldn't the radio transmit on the displayed frequency and any frequency offset to create the tone for CW be done as a receive frequency shift, such as RIT? Maybe the preference has changed.

The CEC firmware has defined settings for the SSB and CW modes, so setting a receive offset in the CW modes would seem like the solution. On the original factory software the solution is not as clear.

Tom, wb6b


Re: boosting the power on 28 MHz #ubitx

 

Thanks for the help, Nick.? I think I will wait until Allison works out the flat power output problem.? 15 meters is my favorite band.
73, WA9PWR


Re: #ubitx #ubitx-help #ubitx-help #ubitx

david todd
 

jack,
I've seen rigs like yours burn just like that and they were commercially built. don't feel so bad. it happens to us all eventually.

73s
david
ka9koj
?


Sent from Yahoo Mail.


Re: #ubitx #ubitx-help #ubitx-help #ubitx

david todd
 

?


Sent from Yahoo Mail. jerry,

you are right a gnd is a ground all the way around. yes the fuse will help on providing a path, but like i said , i would protect it before the fuse because I've worked in the consumer electronics field for 25 years and all the mis wired units I've worked on, was fried. yes a schottky diode is good, . I've seen zeners being used, triacs,optic isolators and other components. but why make it more complicated. some will put a fuse in and throw away the diode to their junk box for another project.some will just use an onboard inline fuse while others may opt for only a diode in series with the hot lead to the switch. and if I'm going to protect my equipment,i use one before the fuse. yes the diode will short out or burn open.ive seen both. and me personally , i wouldn't take the chance to have a positive voltage on my ground plane. a ground is a ground like u said and if any chips or gets on the board are sensitive to a very very brief surge of positive voltage where its supposed to be negative,well i don't want to replace all my equipment I've had for over 35 years since 1980. I've been doing it ever since.yes the diagram is representative of the on/off switch on the audio board. i didn't use that. i installed a toggle switch near the entry point where the source comes in. that way any noise that may be induced into other circuits by running the longer wires are eliminated.And I've seen diodes burn open and the fuse never blew and the fellow hooks it back up the same way and its toast.because the diode is now open and cannot prevent + voltage to ground .that is why i install polarity protection outside of my rigs before the fuse. i don't trust components.


anyway good discussion.
this my own preference of doing things jerry. your suggestions are valid and on the mark.
others will think I'm a crackpot. but if you ever seen ebay filled with $500 or higher rigs where the op hooked up the wrong polarity?
those units should protect from that but a lot are lacking due to the designs. no matter how much the rig is worth.

anyway ?good info and hope to work you on the bands sometime.

73s,

david todd
ka9koj

i


Re: ND6T AGC implementation for uBIT-X

 

I believe Kees is kitting these up for 0805 parts.
The 0805 parts are included with his kit.

An 0805 is 0.08 inches long, 0.05 inches wide.
Rational countries use metric numbers to identify surface mount part sizes.
??

?

On Wed, May 23, 2018 at 10:53 pm, ohwenzelph wrote:
Should the caps and resistors all be 1206 size?


Re: toggle for low output and max output? #ubitx

 

On a somewhat related note, that code of post 44278 conforms with the stock uBitx firmware
in that it keeps the BFO on the low side of the 12mhz crystal filter.
This was done to avoid having audio beat notes between harmonics of?
the 16mhz Nano resonator and the 12mhz BFO.

Playing with my Nano, I don't hear any nasty audio with a high side BFO.
The 16mhz resonator is well away from 16.000 mhz, as it's not terribly accurate.
The 12mhz resonator on the CH340 chip is not active unless cabled up to?
a host computer's USB port.? Convenient, as the 16mhz resonator is the?
only one that is accessible once the Nano is soldered down.? And if one wishes
to communicate with the Nano from a host while using the radio for digital modes,
could use something like the CP2102 of post 50027 if the CH340 is causing grief.

Anyways, might be a good idea to reconsider using a high side clk1 into the second mixer,
always parked at 45mhz+12mhz=57mhz.? Currently it flips between 45-12=33mhz
and 57mhz to select lower sideband and upper sideband operation respectively.
A high side clk1 is preferred, as this will greatly reduce the number of lower frequency
mixer products, and thus reduce the birdie count.?

Though some might prefer to?keep the BFO on the high side of the 12mhz filter.
Crystal ladder filters tend to have a steeper skirt on the upper freq side than on the lower freq side.
? ??
Having the BFO on the upper side improves suppression of the carrier and opposite sideband.

If audio tones from the 16mhz resonator are an issue with some Nano's, a solution might
be to add some capacitance around the resonator to lower the frequency a few khz.
Small caps to ground from ATMega328P pins 7 and 8 where the resonator is wired
should help, but that would be a tricky soldering job for some.
Sticking a finger in there will mess with the resonator considerably,?
a bit of kapton tape and some grounded copper foil should be able to do the same job.?
Better yet, replace the resonator with a crystal of somewhat different frequency??
Or clock the ATMega328P from the BFO, assuming the processor can power up
using some other clock?

Jerry


On Wed, May 23, 2018 at 10:38 pm, Jerry Gaffke wrote:
There are 2 pole and 4 pole variants of that 45mhz crystal filter.
HFSignals is probably using the 2 pole.
If this method of transmitter attenuation is to be used,?
would be best to keep using the same filter.

Looking at the half dozen lines of code here:
? ??/g/BITX20/message/44278
the 45mhz transmit attenuator feature could be implemented by adjusting the value
of c45 during transmit, then returning c45 to its default value during receive.?
Recompute and reload clk1 and vfo into the si5351 with each transition, the bfo can remain fixed.

Will likely be necessary to calibrate each rig once for constant power across bands.
This could be fully automated if there were a diode RF probe on A7
watching the antenna port into a dummy load.

Jerry, KE7ER


Re: ND6T AGC implementation for uBIT-X

 

Should the caps and resistors all be 1206 size?


Re: toggle for low output and max output? #ubitx

 

There are 2 pole and 4 pole variants of that 45mhz crystal filter.
HFSignals is probably using the 2 pole.
If this method of transmitter attenuation is to be used,?
would be best to keep using the same filter.

Looking at the half dozen lines of code here:
? ??/g/BITX20/message/44278
the 45mhz transmit attenuator feature could be implemented by adjusting the value
of c45 during transmit, then returning c45 to its default value during receive.?
Recompute and reload clk1 and vfo into the si5351 with each transition, the bfo can remain fixed.

Will likely be necessary to calibrate each rig once for constant power across bands.
This could be fully automated if there were a diode RF probe on A7
watching the antenna port into a dummy load.

Jerry, KE7ER



On Wed, May 23, 2018 at 10:08 pm, John wrote:
I have uploaded the latest version of my variation on Ian's software with a default of "stock standard" which means it should run on units "factory" wired.

It includes the "OPTION_ALC" where I use a table and interpolation to set the attenuation for? 3 levels (Low, High, Max) for SSB power output.

Not a complex code at all (just search for the "option_alc" keywork). Will give up to around 50dB of attenuation. So should be plenty to control the power even for WSPR low power fans.

I even had to attenuate the signal for "Max" power on 40 and 80m otherwise I would get well passed the targeted 16-17W on the lower frequencies.

But still well short on 10m, so I am following Allison's work on the power chain with great interest.

73, John (VK2ETA)

Software at: /g/BITX20/files/Variations%20on%20KD8CEC%20Software%20%28by%20VK2ETA%29%20+%20ATU%20sketch/uBitx-Raduino-KD8CEC%20based-VK2ETA-Variation%20-%20V20180524.zip


Re: W8TEE vft/tft questions

 

There are some encoders that do put out 4 pulses (two sets of A & B pulses) per detent.?
This has been discussed before.? The fix was to make the code swallow two pulses and
use the other 2 pulses.?

Arv
_._


On Wed, May 23, 2018 at 9:00 PM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:
It appears that your encoder sends out 4 pulses on each detent. I'm not where I can test the code, but try something like this:

void SetEncoderDirection() {
??? int count = 0;

? ? encoderDirection = 0;
????
????newPosition = rotary.read();
??? if (newPosition == 0)
??????? return;

?? while (count < 4) {??????? // Ignore 3 readings

? ????newPosition = rotary.read();
?? ?? if (newPosition != oldPosition) {
? ? ? ?? if (newPosition > oldPosition)
? ? ?????? encoderDirection = 1;
? ?????? else
? ? ????? encoderDirection = -1;
? ????? oldPosition = newPosition;
???? }
??? count++;
}

The idea is to throw away all but the last direction read. Like I said, you'll need to play with it. Also, it will be easier to read your debug code if you don't put things on a new line. Use something like:

#ifdef DEBUG
?if (newPosition != oldPosition) {
? ? ?Serial.print("In SetEncoderDirection old = " );
???? Serial.print(oldPosition);????????????????????????????????????????// No newline here
? ?? Serial.print("?? new = " );
???? Serial.println(newPosition);
?}??????????????????????????????????????????????????????? // Move this one from here....
#endif

If DEBUG is #defined at the top of the file, the debug statements are compiled into the sketch. Comment the #define DEBUG line, and they are no long in the executable, but still can be turned on again if need be.

Jack, W8TEE

On Wednesday, May 23, 2018, 6:13:07 PM EDT, tom.mccobb@... <tom.mccobb@...> wrote:


Hi Jack, thanks for answering.

I have been watching the debug code you mentioned, and the output has changed since things went south.

I added some Serial.print statements of my own.? After watching the debug output for a while, I wanted to know what was going on in SetEncoderDirection:

void SetEncoderDirection() {
? encoderDirection = 0;
? newPosition = rotary.read();
?if (newPosition != oldPosition) {
? ? ?Serial.print("Old: " );
? Serial.println(oldPosition);
? ?Serial.print("New: " );
? Serial.println(newPosition);
?}??????????????????????????????????????????????????????? // Move this one from here....
? if (newPosition != oldPosition) {
? ? if (newPosition > oldPosition)
? ? ? encoderDirection = 1;
? ? else
? ? ? encoderDirection = -1;
? ? oldPosition = newPosition;
? }
}

...and also here, at the top of your debug block:

#ifdef DEBUG?
?Serial.print("Direction: " );
? Serial.println(encoderDirection);? ? ? ? ?
Serial.print("Examine Fast Tune: Start = ");? ? ? ? // May be useful for setting Fast Tune rate
Serial.print(fasttuneStart);
Serial.print("? ?end = ");
Serial.print(fasttuneEnd);
Serial.print("? diff = ");
Serial.println(fasttuneEnd - fasttuneStart);
#endif?

With this in place, I turned the encoder one detent stop, and you see that SetEncoderDirection was called three times.? I kept doing this, slowly, and you can see from the serial monitor output below that even though I am turning the encoder int he same direction, the encoderDirection is variously 1 and -1.? Every 3rd turn the frequency is just not updated at all, but with the vacillating encoderDirection, the freq. goes up 100Hz and down 100Hz.? I thought maybe a bad solder connection was causing a kind of "echo" in the circuit, so I re-flowed the solder to pins 18, 19 and 20.? I have tried a couple of encoders with the debounce caps installed (but who knows, maybe I have a drawer full of bad ones).? I was reading your followup article on encoders and when I got to the end where you suggest always to look for the last thing you think might be wrong, I even changed the connection wires.? Last thing? that I can think of is to swap out the Arduino mini, which I will get to in a day or so (ugh, all those header pins to solder).? If you can suggest anything else, let me know.? Serial output follows:

First turn here:
Old: -1
New: 0
Old: 0
New: -1
Old: -1
New: 0
Direction: 1
Examine Fast Tune: Start = 3324? ?end = 11398? diff = 8074
Old: 0
New: -1
Old: -1
New: 0
Old: 0
New: -1
Direction: -1
Examine Fast Tune: Start = 11539? ?end = 31281? diff = 19742
Old: -1
New: 0
Old: 0
New: -1
Old: -1
New: 0
Direction: 1
Examine Fast Tune: Start = 31422? ?end = 40482? diff = 9060
Old: 0
New: -1
Old: -1
New: 0
Old: 0
New: -1
Direction: -1
Examine Fast Tune: Start = 40623? ?end = 48869? diff = 8246
Old: -1
New: 0