Donchian Channel Stop Loss - pine-script-v5

In Pine Script I'm coding a Donchian Channel trading system, where you go long on a 20-day high, and go short on a 20-day low.
I'm fine with coding the opening and closing of the positions, but I'm struggling with coding the initial Stop-Loss level, which I need to remain *fixed *while the whole position is open.
E.g. When you go long on the break of a 20-day high, I would like the initial stop loss to remain fixed at the 20-day low at the time of entry - and for this stop loss to not change.
I can code other versions of stop losses - like "strategy.position_average_price - atr(4)" but how would I link the stop loss to be fixed at the 20-day low at the point of entry?
Many, many thanks,
David.
DonchianLow=ta.lowest(close[1],20)
strategy.exit("Exit Long", from_entry="Long", stop=strategy.average_position_price - DonchianLow)

You must set your strategy.exit only once.
You can use a piece of code like this :
if strategy.position_size == 0 // no open order
if my_entry_condition
strategy.entry('long', strategy.long, qty=Q_Jetons, limit=limiteachat)
strategy.exit(id='Exit', from_entry="long", stop=StopLoss)
This way your strategy.exit is call one time only, and your SL won't change.

Related

How to force the next node to visit in VRPTWs without changing time window

Let's say I have 3 pairs of pickup and delivery(6 nodes), and their own time windows.
0-Node_start #Index(0)
1-Pickup, 2-Delivery #Index(1,2)
3-Pickup, 4-Delivery #Index(3,4)
5-Pickup, 6-Delivery #Index(5,6)
7-Node_end #Index(7)
How can I force my vehicle to go from node start to index_3, then continue with the rest of the route directly without changing the time window of a node in index_3, or changing the traveling time to 0 from node_0 to node_3? This should be possible regardless of the time taken from index_0 to index_3, as long as time windows allow.
Also, not sure if this is important in this case, but I use FirstSolutionStrategy.GLOBAL_CHEAPEST_ARC
I have found a solution that works for my case, hopeful it will work for others too. I used NextVar
consecutive_locations = [[1,3], [7,9]]
for location_index in consecutive_locations:
routing.solver().Add(routing.NextVar(location_index[0]) == location_index[1])
I used a loop because I have multiple vehicles, each vehicle has a specific starting point, and a location I want it to visit next after starting point.
The solution takes longer though, I think firstSolutionStrategy might be the issue(Not sure)

Raspberry Pi 7 Inch Touchscreen Brightness Control - How to avoid write operation to SD card

I'm just creating an app(kivy) for a raspberry pi(3b) with 7 inch touchdisplay. In addition I implemented a light sensor (TSL2591), which can regulate the brightness of the backlight using following command:
os.system('sudo sh -c "echo '+str(brightness)+' > /sys/class/backlight/rpi_backlight/brightness"')
with values of brightness 0 to 255
Works fine so far, but I do update the brightness once a second. If I'm not wrong, the command overwrites a config file and I mind of write access to the SD Card that often. I think the SD card will be corrupt after a short period of time.
For sure I can try to get less write operations, but it also leads to less smoothness:
update slower than 1 sec
only write if brightness value really changes
don't use all of the 255 steps
So the main question is: is there any other way to control the brightness? Or any workaround? I could not find a "real" Datasheet or any other advice on the internet. So maybe there is another way.
That's not a conventional disk file; it's a "device special file" which the kernel artificially creates to look like a disk file. It allows you to "talk" to device drivers using standard read() and write() calls.
You need not worry about SD card wear.

Health Reporting Stuck

In a simple stateless service I am attempting to report health. As a test I am simply flipping between OK and Warning states on every iteration of my loop in RunAsync (it has a sleep interval of 15secs). The code looks like this:
// report warning on odd iterations
HealthState state = ((++iterations % 2) != 0) ? HealthState.Warning : HealthState.Ok;
HealthInformation health = new HealthInformation("ServiceCode", "Iteration", state);
Partition.ReportInstanceHealth(health);
I am logging the state on each iteration of the loop and the log shows it flipping back and forth. But in the SF Explorer it is stuck on Ok, never switching to Warning (I have a refresh interval of 5secs in SFExplorer).
What am I doing wrong here?
Try specifying HealthInformation.SequenceNumber with an incremental value for every state change.
Looks like health reporting is significantly slower than I would expect. Working on that 15sec interval was not enough time for it to show the alternating health state. Moving to a 30sec interval seems to have resolved it.

GPUImageMovieWriter frame presentationTime

I have a GPUImageColorDodgeBlend filter with two inputs connected:
A GPUImageVideoCamera which is getting frames from the iPhone video camera.
A GPUImageMovie which is an (MP4) video file that I want to have laid over the live camera feed.
The GPUImageColorDodgeBlend is then connected to two outputs:
A GPUImageImageView to provide a live preview of the blend in action.
A GPUImageMovieWriter to write the movie to storage once a record button is pressed.
Now, before the video starts recording, everything works OK 100% of the time. The GPUImageVideo is blended over the live camera video fine, and no issues or warnings are reported.
However, when the GPUImageMovieWriter starts recording, things start to go wrong randomly. About 80-90% of the time, the GPUImageMovieWriter works perfectly, there are no errors or warnings and the output video is written correctly.
However, about 10-20% of the time (and from what I can see, this is fairly random), things seem to go wrong during the recording process (although the on-screen preview continues to work fine).
Specifically, I start getting hundreds & hundreds of Program appending pixel buffer at time: errors.
This error originates from the - (void)newFrameReadyAtTime:(CMTime)frameTime atIndex:(NSInteger)textureIndex method in GPUImageWriter.
This issue is triggered by problems with the frameTime values that are reported to this method.
From what I can see, the problem is caused by the writer sometimes receiving frames numbered by the video camera (which tend to have extremely high time values like 64616612394291 with a timescale of 1000000000). But, then sometimes the writer gets frames numbered by the GPUImageMovie which are numbered much lower (like 200200 with a timescale of 30000).
It seems that GPUImageWriter is happy as long as the frame values are increasing, but once the frame value decreases, it stops writing and just emits Program appending pixel buffer at time: errors.
I seem to be doing something fairly common, and this hasn't been reported anywhere as a bug, so my questions are (answers to any or all of these are appreciated -- they don't all need to necessarily be answered sequentially as separate questions):
Where do the frameTime values come from -- why does it seem so arbitrary whether the frameTime is numbered according to the GPUImageVideoCamera source or the GPUImageMovie source? Why does it alternative between each -- shouldn't the frame numbering scheme be uniform across all frames?
Am I correct in thinking that this issue is caused by non-increasing frameTimes?
...if so, why does GPUImageView accept and display the frameTimes just fine on the screen 100% of the time, yet GPUImageMovieWriter requires them to be ordered?
...and if so, how can I ensure that the frameTimes that come in are valid? I tried adding if (frameTime.value < previousFrameTime.value) return; to skip any lesser-numbered frames which works -- most of the time. Unfortunately, when I set playsAtActualSpeed on the GPUImageMovie this tends to become far less effective as all the frames end up getting skipped after a certain point.
...or perhaps this is a bug, in which case I'll need to report it on GitHub -- but I'd be interested to know if there's something I've overlooked here in how the frameTimes work.
I've found a potential solution to this issue, which I've implemented as a hack for now, but could conceivably be extended to a proper solution.
I've traced the source of the timing back to GPUImageTwoInputFilter which essentially multiplexes the two input sources into a single output of frames.
In the method - (void)newFrameReadyAtTime:(CMTime)frameTime atIndex:(NSInteger)textureIndex, the filter waits until it has collected a frame from the first source (textureInput == 0) and the second, and then forwards on these frames to its targets.
The problem (the way I see it) is that the method simply uses the frameTime of whichever frame comes in second (excluding the cases of still images for which CMTIME_IS_INDEFINTE(frameTime) == YES which I'm not considering for now because I don't work with still images) which may not always be the same frame (for whatever reason).
The relevant code which checks for both frames and sends them on for processing is as follows:
if ((hasReceivedFirstFrame && hasReceivedSecondFrame) || updatedMovieFrameOppositeStillImage)
{
[super newFrameReadyAtTime:frameTime atIndex:0]; // this line has the problem
hasReceivedFirstFrame = NO;
hasReceivedSecondFrame = NO;
}
What I've done is adjusted the above code to [super newFrameReadyAtTime:firstFrameTime atIndex:0] so that it always uses the frameTime from the first input and totally ignores the frameTime from the second input. So far, it's all working fine like this. (Would still be interested for someone to let me know why this is written this way, given that GPUImageMovieWriter seems to insist on increasing frameTimes, which the method as-is doesn't guarantee.)
Caveat: This will almost certainly break entirely if you work only with still images, in which case you will have CMTIME_IS_INDEFINITE(frameTime) == YES for your first input'sframeTime.

Improve Arduino WiFly latency using protol

I have an Arduino with a WiFly shield, everything works perfectly!
The thing is, when I want to turn on an LED, I open in my
webbrowser:
192.168.1.120/ledon/
(I made a program which handles this URL).
But the thing is; when I make a request, I must wait 1-2 seconds before I can do another one.
So, it is very long, and if I want to control motors, it is just too long.
So, instead of using an HTTP request, I want to use something else which can be faster.
Something "super fast".
I just need to tell the Arduino:
- go direction 1
- go direction 2...
- turn on LED
- turn off LED
- tell me the light level (which return a int)
So it is just about a small amount of data.
Can you show me a way? (Telnet, UDP, OSC?)
For your arduino, have a look at just using sockets or even encoding the data in the URL requested.
You shouldnt get less than about 0.8 Seconds Lag maximum.
How big is your program for handling the Url /ledon/ ?
Using pure packets (usually TCP) from your computer to the arduino is faster sometimes..
But you may need to code a application to handle the packets on the pc.
There is the option of Javascript to parse data back and forth e.g. reading the light level and such.